-
Notifications
You must be signed in to change notification settings - Fork 11
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
Update pathogen-repo-ci to "generic"/"smart" workflow #89
Comments
100% support this direction. One additional check I would add to the |
+1 from me. For the calling workflow in each repo, I'd extend the default set of triggers, e.g. something like on:
push:
branches:
- main # or "master", as required
pull_request:
workflow_dispatch:
# Routinely check that we continue to work in the face of external changes.
schedule:
# Every day at 17:42 UTC / 9:42 Seattle (winter) / 10:42 Seattle (summer)
- cron: "42 17 * * *" |
Let me tug on this thread a little...
Generally, for CI, I want it to run when anything changes — like, I want to be able to push a branch and trigger it without opening a PR (because I'm still developing and just want the sanity check that I haven't broken anything so far). (Aside: At one point I had both The |
Added to the sketch above. |
I understand where you're coming from, but I disagree. From my rationale in nextstrain/cli@fab709a:
|
This should be handled within the build-config of the consuming repo if it is required.
…89] Has the side benefit of allowing the `run-nexstrain-build` action to also be invoked from the sidecar instead of pinned to `master` or some other version.
…89] Has the side benefit of allowing the `run-nexstrain-build` action to also be invoked from the sidecar instead of pinned to `master` or some other version.
…89] Has the side benefit of allowing the `run-nexstrain-build` action to also be invoked from the sidecar instead of pinned to `master` or some other version.
Also update nextstrain runtime setup step to use "modern" sidecar version, which has the side effect/benefit of allowing the `run-nexstrain-build` action to also be invoked from the sidecar instead of pinned to `master` or some other version.
* run-nextstrain-build-step -> run-nextstrain-build * inputs.step -> inputs.directory
Also update nextstrain runtime setup step to use "modern" sidecar version, which has the side effect/benefit of allowing the `run-nexstrain-build` action to also be invoked from the sidecar instead of pinned to `master` or some other version.
* run-nextstrain-build-step -> run-nextstrain-build * inputs.step -> inputs.directory
…per PR feedback * ignore/don't warn when no files found * include `auspcice` directory in upload set * sort lines
…89] * Pass `runtime` as an input, rather than accessing `matrix.runtime` directly * Update action description to reflect dependency on having Nextstrain CLI already set up via other action; add warning about the purpose of this action
* Update `artifact-name` description in `pathogen-repo-ci.yaml` to make it clear build directory will be appended to provided value, and to update default value to make clear these are CI results * Pass `artifact-name` down into `run-nextstrain-ci-build` steps ni `pathogen-repo-ci` workflow * Add `artifact-name` input to `run-nextstrain-ci-build` action and use it in `upload-artifact` action step
Context
Per recent discussion, as well as various legacy conversations here, here, and here, we want to update the
pathogen-repo-ci
GitHub Action to a "strict" version that can be used across all of our "modern" pathogen repos with zero configuration on the consuming repo side.Description
Update the
pathogen-repo-ci
workflow so that:nextstrain-pathogen.yaml
file is presentingest
,phylogenetic
, andnextclade
):a. If the repo contains a
<build-name>/Snakefile
file and a<build-name>/build-configs/ci/config.yaml
fileb. Run
nextstrain build <build-name> --configfile build-configs/ci/config.yaml
The consuming repo will be responsible for providing an appropriate config file that either sets up appropriate example data or results in a subset of a full workflow being run, so as to validate that the repo workflows have not been broken by a change.
Examples
This workflow, plus the appropriate build-config files, should be sufficient to enable CI for a pathogen repo:
The text was updated successfully, but these errors were encountered: