CI: Build Auspice client #599
Conversation
Same reasoning as @tsibley in nextstrain/cli@fab709a: Running on push _and_ PRs is often redundant. For PRs, we really care about the putative merge of the PR branch, and that's what "on: pull_request" tests. We typically do not need push-level CI results for PRs. On the other hand, CI results for every push to master are nice to have both as a safety backstop and for the linear chain of CI history it produces (e.g. to debug the impact of external changes on our CI). The primary downside I see is that you can no longer push without opening a PR just to see what CI says, but I think that's an acceptable tradeoff, especially now that draft PRs are a thing. To mitigate this downside, "on: workflow_dispatch" allows CI to be manually dispatched for a specific branch/tag/commit if you _really_ don't want to open even a draft PR. Trimming unnecessary CI jobs reduces the time to completion for CI runs (good for the dev loop) and reduces organization-level job queuing, which can negatively impact the workflows of other repos. Co-authored-by: Thomas Sibley <[email protected]>
It can be useful to test that a newer Auspice version builds properly in the context of this project.
nextstrain-bot
temporarily deployed
to
nextstrain-s-victorlin--5z2czf
|
This should be covered by our normal CI ( The scenario I brought up is where we want to try to build a specific (new / development) version of auspice within the nextstrain.org repo. This requires something along the lines of |
@jameshadfield oh you're right! This PR isn't needed then. Yes, nextstrain/auspice#1565 should be sufficient. |
|
I'd still +1 this though: b057b77 |
Description of proposed changes
It can be useful to test that a newer Auspice version builds properly in the context of this project.
Related issue(s)
Testing scenario brought up by @jameshadfield in nextstrain/auspice#1520 (comment).
Testing