Conversation
this was improperly cleaning up packages built in the host's package dir
This was referenced Jun 9, 2025
The recipe `ligand-validation` was added with an empty `extra:` section in meta.yaml. This will handle that situation without throwing an error during the nightly ARM builds.
d9b34c0 to
b7104d2
Compare
so that the `test` job can use build-images job as a dependency. Otherwise, if build-images is skipped, test would be skipped.
Contributor
|
@ALL! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, the various bioconda images were built in different places (
bioconda-containersandbioconda-utils) using different methodologies and repeated-but-not-quite-the-same code.This PR aims to consolidate all image building into a single location
The location is here in
bioconda-utilsbecause 1) images are tightly coupled to the bioconda-utils version, 2) it is much more straightforward to handle everything in the same GitHub Actions workflow rather than try to coordinate across repos, and 3) consolidating means we can actually capture the dependencies between images (in ways that were not actually being captured previously).Here are the dependencies, for reference:
graph TD; base-busybox-->build-env; bioconda-utils-->build-env; build-env-->create-env; create-env-->bot; create-env-->A["final builds"]; build-env-->A["final builds"]; base-debian-->A["final builds"]; bioconda-utils-->A["final builds"]; style bioconda-utils fill:#f9f,stroke:#333,stroke-width:4pxSee dockerfile inventory for some background on how the images are used. There are details on that page that will need to be updated once this is merged in and the containers are being used in production.
Briefly, this PR:
imagesimages/image_config.shandimages/build.shto control the builds.github/workflows/build-images.ymlGHA workflow to orchestrate the buildingcreate-envimageSee
images/README.mdfor details, including how to run locally.This replaces #1046, #959, and #953 which had a LOT of troubleshooting; commits have been cleaned up and rebased into this this PR. Those other PRs attempted to encode the DAG in the GitHub Actions workflow and use caching in various ways for parallel builds. The problem was that it was too hard to keep all the moving parts in your head, especially returning to it after a while. I thought this complexity posed a risk to long-term maintenance burden. So this PR has all images created in the same GitHub Actions job, no clever caching or dependencies across GHA jobs. This has a time cost -- it takes about an hour to build everything -- but in practice these will not need to be rebuilt often.
The following is the proposed workflow for images, from PR through release-please. It includes thinking about which tags should get pushed when.
For example, a merge to master pushes
mastertagged manifests to quay.io. These are overwritten on each push to master. In this way, the:mastertag sort of behaves like thelatesttag conventionally does, but it only applies to the master branch. Note that we can't use the new release version number at this time because release-please has not been run (where it creates a new tag and release).Then when release-please runs, it takes whatever existing manifest is tagged as master and creates two new tags: 1) a tag reflecting the bioconda-utils release and 2)
latest.So
masterwill always refer to the latest images built on the master branch, andlatestwill always refer to the most recent release.