As the workflows have matured, some of the target names do not necessarily make sense anymore.
Background
There are two main things these extensions to the build harnesses focuses on:
Architecture awareness for docker builds
Deterministic versioning scheme based on docker describe and annotated tagging in release branches
Enhancements to
For architecture awareness it is required that architecture is added to docker builds.
Currently this is implemented via
docker/arch/build and docker/arch/image/push
This is basically adding "architecture awareness" to the upstream docker/build and docker/image/push targets.
For the deterministic versioning scheme the extensions makes some variables populated by git describe These are currently used in our workflow (by configuration) to populate the TARGET_VERSION variables used by docker/build and docker/image/push
We also introduce a concept of <release>-latest meaning latest build from a given branch
For a more logical flow when doing builds I propose
This would introduce a new target docker/image/push/release-latest to deprecate docker/image/tag-and-push
Multi-arch builds:
(on each architecture)
- docker/arch/build # builds somewhere/myimage:3.1-5-gac42564c_{amd64,ppc64le,s390x}
- docker/arch/image/push # pushes somewhere/myimage:3.1-5-gac42564c_{amd64,ppc64le,s390x}
(on single node job at end)
- docker/arch/manifest/build # creates somewhere/myimage:3.1-5-gac42564c
- docker/arch/manifest/push # pushes somewhere/myimage:3.1-5-gac42564c
- docker/arch/manifest/push/release-latest # pushes somewhere/myimage:3.1-latest
This would introduce three new targets "under" docker/arch/manifest to deprecate docker/fatmanifest/build
Same, we currently have a target operatorsdk/build which is implicitly architecture aware, but we should really follow the same convention of operatorsdk/build being architecture agnostic, and opoeratorsdk/arch/build being architecture aware.
(on each architecture)
- operatorsdk/arch/build
- docker/arch/image/push
(on single node job at end)
- docker/arch/manifest/build
- docker/arch/manifest/push
- docker/arch/manifest/push/release-latest
I think the main thing I'm seeking is a common convention that
arch is inserted in "normal" targets to indicate architecture awareness <module>/arch/<action> vs <module>/<action>
release-latest is explicitly spelled out when pushing the moving tag to indicate latest build for a release
As the workflows have matured, some of the target names do not necessarily make sense anymore.
Background
There are two main things these extensions to the build harnesses focuses on:
For architecture awareness it is required that architecture is added to docker builds. Currently this is implemented via
docker/arch/build
anddocker/arch/image/push
This is basically adding "architecture awareness" to the upstreamdocker/build
anddocker/image/push
targets.For the deterministic versioning scheme the extensions makes some variables populated by
git describe
These are currently used in our workflow (by configuration) to populate the TARGET_VERSION variables used bydocker/build
anddocker/image/push
We also introduce a concept of
<release>-latest
meaning latest build from a given branchFor a more logical flow when doing builds I propose
Single architecture builds:
This would introduce a new target
docker/image/push/release-latest
to deprecatedocker/image/tag-and-push
Multi-arch builds:
This would introduce three new targets "under"
docker/arch/manifest
to deprecatedocker/fatmanifest/build
Same, we currently have a target
operatorsdk/build
which is implicitly architecture aware, but we should really follow the same convention ofoperatorsdk/build
being architecture agnostic, andopoeratorsdk/arch/build
being architecture aware.Single Architecture flow
Multi-arch:
I think the main thing I'm seeking is a common convention that
arch
is inserted in "normal" targets to indicate architecture awareness<module>/arch/<action>
vs<module>/<action>
release-latest
is explicitly spelled out when pushing the moving tag to indicate latest build for a release