Redesign - target names

[hassenius]

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:

1. Architecture awareness for docker builds
2. Deterministic versioning scheme based on docker describe and annotated tagging in release branches
3. 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

Single architecture builds:

- docker/build # builds somewhere/myimage:3.1-5-gac42564c
- docker/image/push # pushes somewhere/myimage:3.1-5-gac42564c
- docker/image/push/release-latest # pushes somewhere/myimage:3.1-latest

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.

Single Architecture flow

- operatorsdk/build
- docker/image/push
- docker/image/push/release-latest`

Multi-arch:

(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

[hassenius]

@greenegeek @taylormgeorge91 for your input

[hassenius]

@amar-k for consideration

[greenegeek]

@hassenius This makes sense to me.