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

ci: Test pathogen repo CI builds with the final packages #27

Merged
merged 1 commit into from
May 12, 2023

Commits on May 11, 2023

  1. ci: Test pathogen repo CI builds with the final packages

    [ Commit message based on that of 12000a20 in nextstrain/docker-base.¹
      Code changes also based on that commit, plus subsequent commits.² ]
    
    A useful check for if new packages will break our pathogen builds.
    
    I included all pathogen repos that already use our pathogen-repo-ci
    reusable workflow.  It should be minimal effort to maintain this list
    over time—I expect it to only grow—but perhaps in the future we will
    want to abstract it out into a shared list of known pathogen repos.
    
    I don't like that we have to copy the build-args for a few of the repos
    here since it'll be easy for this copy to diverge from the repo's
    authoritative build-args, but it's necessary for now.  Over time as we
    work towards increased automation of pathogen builds, I think we can get
    rid of this build-args copy by further standardizing how each repo
    configures itself for automation.  For example, instead of specifying
    build-args in a repo's CI workflow, the args for CI could be stored in a
    broader workflow metadata file (e.g. nextstrain-workflow.yaml) read by
    pathogen-repo-ci, or defined by some other convention.
    
    An alternative to directly running pathogen-repo-ci against each repo
    here would be instead triggering the CI workflows themselves within each
    repo.  The downside to that is it would divorce the outcomes of those
    workflows from this one and render them not visible from PRs in this
    repo.  It would also require updates to each repo to support triggering
    and passing in of additional parameters (i.e. for the package).  And
    finally those CI workflows sometimes run other jobs, like linting and
    other integration tests (e.g. with Cram), that aren't always necessary
    to run with a new package.
    
    Related-to: <nextstrain/docker-base#148>
    Related-to: <nextstrain/docker-base#150>
    Related-to: <nextstrain/docker-base#151>
    Related-to: <nextstrain/docker-base#154>
    
    ¹ <nextstrain/docker-base@12000a20>
    ² <nextstrain/docker-base@bc22a0bc>
      <nextstrain/docker-base@0a20a474>
      <nextstrain/docker-base@75254e92>
    tsibley committed May 11, 2023
    Configuration menu
    Copy the full SHA
    84ba40c View commit details
    Browse the repository at this point in the history