Release automation should support building a subset of microsoft/go-images
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 431
- Forks
- 44
- Avg merge
- 21h 18m
- Merged PRs (30d)
- 30
Description
The release-go-images pipeline only supports building the full set of images. It could instead have some way to only build/release a certain set of Dockerfiles. (The infra has a pattern-matching system to use when queueing the go-images internal build directly, but we would need to modify our release automation pipelines to pass along this value.)
This would likely only be used when we identify an issue in one of our patch files and need to e.g. ship a 1.18.3-2 revision update but leave 1.17.x alone. This situation is expected to be rare.
A way that a dev could work around this now is to reject the release-go-images pipeline rather than approving it, and run the Go build manually. For now, this doesn't seem like a particularly burdensome workaround.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the release-go-images pipeline and the Dockerfiles it builds. Trace how the internal go-images build is queued and how its pattern-matching value could be passed through; done means a release can select a subset of images while the existing full-build behavior remains unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- build-system, ci-cd, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100