-
Notifications
You must be signed in to change notification settings - Fork 617
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
multi-architecture builds and publish #1681
Conversation
4935911
to
506369a
Compare
awx-operator/.github/workflows/publish-operator-hub.yaml Lines 78 to 86 in 07427be
which leads to awx-operator/hack/publish-to-operator-hub.sh Lines 43 to 45 in 07427be
As part of the publish there is another build and push of the image. Can this be safely removed? AS the complete manifest is already pushed to quay.io in the Lines 235 to 237 in 07427be
Also I noticed that step |
Don't know who to ping, PR ready for review. also require someone in the know to answer my above question |
The
The A catalog image is a 3rd image that contains pointers to operator bundle versions it knows about, which populates the list of available operators that can be installed on Openshift or an OLM enabled k8s cluster. The newer catalog images are just plaintext on the inside as far as I know (file-based-catalogs) as far as I know. This is not strictly needed for users as the folks from https://github.com/k8s-operatorhub/community-operators maintain a catalog image that gets installed as part of OLM when you install an operator from OperatorHub.io. So I don't think we need to worry about multi-arch for these images. |
@jon-nfc it looks like there are a few linting issues that need to be cleaned up.
|
As there are ENV vars set by the build process, there needs to be a way of passing them at build time PR ansible#1681
As part of the release process, env vars for the operator and awx must be set. As such the image needs to be rebuilt. PR ansible#1681
I though as much. |
@jon-nfc I think this is a good approach. I didn't spot any issues while reading this through except for one more linting error CI is complaining about. I would like to run through a mock release on my fork first though before merging. I'll plan on doing that tomorrow.
cc @TheRealHaoLiu for review as well. |
42:1 [empty-lines] too many blank lines (1 > 0) PR ansible#1681
Righto, I'll have everything good to go in the next few hours.
depends on where you are, where i am it could still be yesterday for you. |
.github/workflows/stage.yml
Outdated
IMAGE_TAG_BASE=ghcr.io/${{ github.repository_owner }}/awx-operator \ | ||
VERSION=${{ github.event.inputs.version }} make docker-build docker-push | ||
--build-arg OPERATOR_VERSION=${{ github.event.inputs.version }}" \ | ||
IMG=ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:${{ github.event.inputs.version }} \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMG=ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:${{ github.event.inputs.version }} \ | |
IMG=ghcr.io/${{ github.repository }}:${{ github.event.inputs.version }} \ |
We need to remove ${{ github.repository_owner }}
here because it is already there from when it is set during the checkout:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awx-operator/.github/workflows/stage.yml
Lines 46 to 50 in 4d79365
- name: Checkout awx-operator | |
uses: actions/checkout@v3 | |
with: | |
repository: ${{ github.repository_owner }}/awx-operator | |
path: awx-operator |
I did not know this, however note taken.
question, re variable preceedence
awx-operator/.github/workflows/stage.yml
Lines 40 to 50 in 4d79365
- name: Checkout awx | |
uses: actions/checkout@v3 | |
with: | |
repository: ${{ github.repository_owner }}/awx | |
path: awx | |
- name: Checkout awx-operator | |
uses: actions/checkout@v3 | |
with: | |
repository: ${{ github.repository_owner }}/awx-operator | |
path: awx-operator |
there are two checkouts, which variable takes precedence? first set, last set?
molecule (--skip-tags=replicas): .github/workflows/devel.yaml#L41 41:65 [new-line-at-end-of-file] no new line character at the end of file PR ansible#1681
molecule (--skip-tags=replicas): .github/workflows/devel.yaml#L41 41:65 [new-line-at-end-of-file] no new line character at the end of file PR ansible#1681
6d0ba09
to
4d79365
Compare
.github/workflows/devel.yaml
Outdated
run: | | ||
docker buildx imagetools create \ | ||
ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:${{ github.sha }} \ | ||
--tag quay.io/ansible/${{ github.repository }}:devel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know if there is an issue with the linter but it inconsistent.
- 466b0cf too many blank lines
0>1
when there were two blank lines https://github.com/ansible/awx-operator/actions/runs/7457722546 - 4d79365 no blank line at end of file
no new line character at the end of file
https://github.com/ansible/awx-operator/actions/runs/7470471612
A default set of platforms is specified and will build those if var `PLATFORMS` is not specified on the CLI Issue ansible#31 fixes ansible#1680
1. builds containers and stores @ghcr with tag that is git commit. 2. pushes the image to quay.io/ansible with tag devel. Issue ansible#31
It's not good practice to rebuild images as the scenario exists where the same code base builds different images. As such only use images from a single build point. 1. Pulls the image that matches the git commit 2. Tag image with the specified version and push to ghcr Issue ansible#31
…i-arch manifest 1. Pulls the complete manifest containing all architectures that matches the version from ghcr 2. Tag manifest with the specified version and publish to quay.io 3. Tag manifest as 'latest' and publish to quay.io fixes ansible#31
As there are ENV vars set by the build process, there needs to be a way of passing them at build time PR ansible#1681
As part of the release process, env vars for the operator and awx must be set. As such the image needs to be rebuilt. PR ansible#1681
42:1 [empty-lines] too many blank lines (1 > 0) PR ansible#1681
molecule (--skip-tags=replicas): .github/workflows/devel.yaml#L41 41:65 [new-line-at-end-of-file] no new line character at the end of file PR ansible#1681
4d79365
to
9442e0a
Compare
branch updated with rebase. PR ready for review |
.github/workflows/promote.yaml
Outdated
ghcr.io/${{ github.repository_owner }}/${{ github.repository }}:${TAG_NAME} \ | ||
--tag quay.io/ansible/${{ github.repository }}:${TAG_NAME} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GITHUB_REPOSITORY | The owner and repository name. For example, octocat/Hello-World.
i think we need to take in a variable for "which quay repo to push this to"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i have an outstanding question above re this from the review that @rooftopcellist did. That's why the discussions are not resolved as the next reviewer can see and resolve as completed and as appropriate.
#1681 (comment). this question still remains!!!!
@jon-nfc , @TheRealHaoLiu and I tested out this workflow on our fork today and got it working with the changes in this PR. Mainly, we modified how it runs so that we could test it on a fork and push the images to our personal quay registry so as not to affect the official awx-operator images while testing. There were also a few variable refs that needed to be changed for the workflow to work. Notably:
I also changed how it creates the draft release so that it uses the github action for it rather than custom logic to git the GitHub API. I opened a PR to your branch here: Note that a variable needs to be created in the GitHub repo if you want to override the default when triggering the promote pipeline by publishing the draft release: Here is the successful test release on my fork: |
Modify Release GHA to run on fork
SUMMARY
Add changes related to multi-architecture builds and publishing.
The desired endstate is that there is officially built and supported multi-architecture container images that can be built from a single command
make docker-buildx
and that on quay.io/ansible/awx-operator those same muli-architecture images are available for consumption.ISSUE TYPE
ADDITIONAL INFORMATION
This PR does not have the intention of changing the release workflow. The intent is that as part of the established workflow, that multi-architecture containers are built and published for use by the community.
Adjustment was made to ensure that there is ever only one image built for a given git commit and is used for the entire workflow. This prevents the scenario where it's as if a witch has casted a spell upon you, when at the end of the day there were two or more images that exist for the same commit and you were the poor sole who can't figure out what is wrong because the image you have is "Good to go!!" Bottom line no one wants to debug black magic (be in a scenario where two images exist for the same code but are different enough to make you pull your hair out). As each commit is stored on GHCR, it becomes the single source of truth for any containers built, especially for debugging purposes.
Changes to Github Actions
devel push to devel branch builds multi-arch containers and tags it with the git commit and stores it on GHCR in addition to the existing step of pushing said manifest to quay.io with the
devel
tagstage when triggered no longer builds it's own image. pulls the image from GHCR built in
devel
action and follows the existing flow of tagging with the specified version and pushing back to GHCRpromote Github Release No change, however now uses the multi-arch manifest.
Other Changes
reference: ansible/eda-server-operator#158
makefile now has a target
docker-buildx
this target provides the basis for all multi-arch container builds. As buildx creates a manifest with all container architectures included, as part of the same command will automagic push the image to the tagged registry. This command can also be used in developmentmake docker-buildx
IMG=registry/name/name2:tag make docker-buildx
.PLATFORMS=linux/arm64,linux/amd64 make docker-buildx
Fixes issues