Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deal with long running processes? #52

Open
sckott opened this issue Dec 20, 2024 · 0 comments
Open

How to deal with long running processes? #52

sckott opened this issue Dec 20, 2024 · 0 comments
Labels
question Further information is requested

Comments

@sckott
Copy link
Collaborator

sckott commented Dec 20, 2024

(pulling info from a slack thread convo with @dtenenba on 2024-12-20 so it doesn't get lost)

We have some "long" running processes that we'll have to deal with for tests. Long here may be 30 seconds or multiple hours, both of which need specific handling - a request to get metadata about job X after 2 seconds may error or return a different set of data than the same request after job X has completed.

Some options:

  • use test fixtures - record a real http response and then use that cached http response insetad of making a real request to the cromwell server - this will be very fast
  • use mocks - similar to fixtures, but instead of the whole http response saved to a file that we read (the fixture) we just specify the returned json in a variable
  • forget about tests that depend on longer running operations? seems not ideal
  • on a cron schedule submit all the wdls/jsons that have longer running operations - say once a day - when we run tests we just use the results already in the test user DB

If things can take a long time and we're okay with that (we don't use the above approaches of fixtures, mocks, etc.), then we need a different testing setup than is typical (where you do X and Y and then run the unit test right away). How would that work?

Some background info:

curl -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer YOUR_GITHUB_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/actions/workflows/WORKFLOW_ID/dispatches \
  -d '{"ref":"main"}'

It's not clear yet what the solution is, but likely involves some system where one workflow (.yml file) submits workflows, then another runs tests that depend on those workflows (presumably all in final state on cromwell) - how the 2nd system knows when to run is up for debate; possibly some script polling for all workflows being done

@sckott sckott added the question Further information is requested label Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant