-
Notifications
You must be signed in to change notification settings - Fork 134
feat: containers overhaul #1049
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
Open
daler
wants to merge
19
commits into
master
Choose a base branch
from
containers-overhaul
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
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
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.
|
@ALL! |
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.