Add Release Workflow and Single Command Install artifact #159

rooftopcellist · 2024-01-04T04:59:01Z

This PR adds a make target to generate a single yaml file that can be applied to install the operator for a particular version.

This yaml file will be added as a release artifact for operator releases.

This PR also adds a GHA for automating releases.

Related issues this will resolve:

rooftopcellist · 2024-01-05T04:02:18Z

I tested this out on my fork and it now works. Here is an example of a draft release:

Things that will be needed:

the current QUAY_TOKEN will need to grow permissions for the bundle and catalog quay.io registries.

rooftopcellist · 2024-01-06T02:52:37Z

We should double check that the one line operator.yaml artifact deploys a working eda-server-operator when applied. Then we should be sure to document this install method to make users aware of it. We should include how to upgrade using the one line install too and test that.

.github/workflows/release.yaml

rooftopcellist · 2024-01-08T21:12:45Z

I tried running this on my fork and it works as expected, but fails on the bundle push atm. That is because I need to get the permissions added tot he quay token, once done, we can merge this and put out our first stable major version of the operator, v1.0.0!

rooftopcellist · 2024-01-08T21:45:26Z

@jon-nfc Unfortunately, since we need to be able to pin the version of the eda-server and eda-ui images at build time of the operator, that poses a problem for this approach of using the pre-built images from devel, re-tagging, and releasing them...

With that in mind, unless you have any other ideas, I think we should revert the last commit, as the next change I intend to make is to add pinned default versions via env vars to resolve this issue:

Pin API and UI image refs in released operator images #125

I went ahead and reverted it for now, but it is still open for discussion.

.github/workflows/release.yaml

jon-nfc · 2024-01-09T07:20:25Z

@jon-nfc Unfortunately, since we need to be able to pin the version of the eda-server and eda-ui images at build time of the operator, that poses a problem for this approach of using the pre-built images from devel, re-tagging, and releasing them...

With that in mind, unless you have any other ideas, I think we should revert the last commit, as the next change I intend to make is to add pinned default versions via env vars to resolve this issue:

Pin API and UI image refs in released operator images #125

I went ahead and reverted it for now, but it is still open for discussion.

is the work from ansible/awx-operator#1681 (comment) portable to this repo? Although chain of build does change, it would remain the same for the release cycle as the cycle starts at "staging"

Edit:

this mthod simillar to the implementation in ansible/awx-operator#1681, would have the dev build tied to the it hash, as the "internal testing image" and the release image, which starts from "staging" as the only image existing of that version in "the wild" / released to the public

Makefile

jon-nfc

done. only issue I noticed was inconsistency between main and latest image tags

jon-nfc · 2024-01-10T05:12:54Z

.github/workflows/release.yaml

+      - name: Build Bundle Image
+        run: |
+          make bundle IMG=eda-server-operator:${{ github.event.inputs.version }} VERSION=${{ github.event.inputs.version }}
+          make bundle-build BUNDLE_IMG=eda-server-operator-bundle:${{ github.event.inputs.version }}


You'll have to forgive my unfamiliarity....

I'm assuming that the docker file in this step is created as part of this line, in the bundle target?

eda-server-operator/Makefile

Line 176 in f237b95

$(KUSTOMIZE) build config/manifests | $(OPERATOR_SDK) generate bundle -q --overwrite --version $(VERSION) $(BUNDLE_METADATA_OPTS)

Absolutely correct. When make bundle is run, it generates the bundle.Dockerfile, which is used by make bundle-build.

/home/chadams/eda-server-operator/bin/kustomize build config/manifests | /home/chadams/bin/operator-sdk generate bundle -q --overwrite --version 0.0.1 INFO[0000] Creating bundle.Dockerfile

jon-nfc · 2024-01-10T05:31:59Z

README.md

+
+## Maintainers Docs
+
+Maintainers of this repo need to carry out releases, triage issues, etc. There are docs for those types of administrative tasks in the `docs/maintainer/` directory.


Food for thought, maintainer and contributing docs be moved to a central location.

Thought Process. I know of at least three repos in the ansible org where the structures and processes appear the same:

awx

awx-operator

eda-operator

A single location for common items give a single point for them to be updated and referenced by all. Normalizing the processes, i.e Actions, Workflows, Contributing, Dev etc. Reduces the burden on those who work on the repos as now they need to learn one process to work on "Ansible" repos and the process they learn is portable to all repos. An update to the source docs, should add a workflow item to review and refactor a repos "processes" to be in line and ensures it remains up to date and inline with best practices.

@jon-nfc I 💯 agree. We an internal repo where we could potentially put standard release docs like that, but no public equivalent. I really want to keep these docs public.

A step in the right direction would be to have a single set of docs for Actions, Workflows, Contributing topics in one of those mentioned repos (maybe awx?), then to link to that from the other repo's readme's. However, having a central place would be better, as a landing page for people interested in contributed to any of the Ansible related repos.

The developer docs will still be largely different for each repo, as developing for say ansible-core, will be vastly different then awx, or any of the operators. But I could certainly see a single development.md doc for all of the operators.

There is leg work needed to standardize these processes in each operator repo, and arguably more to be done in the application repos (awx, eda, galaxy_ng), but it is definitely worth the time. I think we should capture this in a separate issue.

docs/user-guide/advanced-configuration/deploying-a-specific-version.md

roles/eda/defaults/main.yml

- This will make it possible for users to install the operator by applying yaml for a particular version without cloning the repo.

Co-authored-by: Jon <[email protected]>

This reverts commit 80d14d4.

- Push the latest tag as well Signed-off-by: Christian M. Adams <[email protected]>

- push the stage operator image to ghcr.io, to be used by the promote workflow later Signed-off-by: Christian M. Adams <[email protected]>

rooftopcellist · 2024-01-10T23:39:40Z

With the latest set of changes, the release workflow (stage and promote) are now both working!

With that, this is ready to merge.
cc @dsavineau

dsavineau

some comments and minor improvements but could be done as a follow up PR

.github/workflows/release.yaml

Co-authored-by: Dimitri Savineau <[email protected]>

rooftopcellist · 2024-01-12T03:50:57Z

Thanks for the review! I made those changes and ran through the workflow again. This time I also tested the flow of publishing the draft release to trigger the promote workflow, this surfaced a couple more var referencing issues that didn't fail when using the workflow_dispatch flow.

Everything works now, I am going to go ahead and merge this. Thanks for the great collaboration here y'all!

goldyfruit · 2024-01-12T12:34:50Z

Awesome 👍

rooftopcellist marked this pull request as ready for review January 5, 2024 04:07

jon-nfc mentioned this pull request Jan 8, 2024

Enable multi-arch builds in GHA for the main branch #161

Merged

jon-nfc reviewed Jan 8, 2024

View reviewed changes

.github/workflows/release.yaml Outdated Show resolved Hide resolved

rooftopcellist force-pushed the release-yaml-artifact branch from 517eca3 to 80d14d4 Compare January 8, 2024 21:06

dsavineau reviewed Jan 8, 2024

View reviewed changes

.github/workflows/release.yaml Outdated Show resolved Hide resolved

jon-nfc mentioned this pull request Jan 9, 2024

Pin API and UI image refs in released operator images #125

Closed

dsavineau reviewed Jan 9, 2024

View reviewed changes

Makefile Outdated Show resolved Hide resolved

rooftopcellist force-pushed the release-yaml-artifact branch from 11793a6 to f237b95 Compare January 10, 2024 04:25

rooftopcellist requested review from jon-nfc and dsavineau January 10, 2024 04:26

jon-nfc reviewed Jan 10, 2024

View reviewed changes

rooftopcellist and others added 8 commits January 10, 2024 15:49

Add a make target to generate a single yaml file to apply for install

8d4eb49

- This will make it possible for users to install the operator by applying yaml for a particular version without cloning the repo.

Add GHA for releasing the operator

f7c9594

Add Table of Contents to README.md

4601700

Additions needed to make Release workflow work

572055c

Use the pre-built images per commit hash on ghcr.io

6b2d6c6

Co-authored-by: Jon <[email protected]>

Revert "Use the pre-built images per commit hash on ghcr.io"

05ce8e1

This reverts commit 80d14d4.

Build multi-arch images when releasing

5874812

- Push the latest tag as well Signed-off-by: Christian M. Adams <[email protected]>

Fix ARCH var typo and remove task to install operator-sdk binary

116eb25

rooftopcellist force-pushed the release-yaml-artifact branch 2 times, most recently from d12a9f4 to 6381a5a Compare January 10, 2024 21:10

Add GHA to stage the release before publishing

d5f5fa6

- push the stage operator image to ghcr.io, to be used by the promote workflow later Signed-off-by: Christian M. Adams <[email protected]>

rooftopcellist force-pushed the release-yaml-artifact branch from 6381a5a to d5f5fa6 Compare January 10, 2024 22:18

Fix release promote action

29a2d54

dsavineau approved these changes Jan 11, 2024

View reviewed changes

rooftopcellist commented Jan 12, 2024

View reviewed changes

.github/workflows/release.yaml Outdated Show resolved Hide resolved

Consolidate push to registry tasks and use latest GHA versions

73008e8

Co-authored-by: Dimitri Savineau <[email protected]>

rooftopcellist force-pushed the release-yaml-artifact branch from e21aaea to 73008e8 Compare January 12, 2024 02:50

rooftopcellist added 5 commits January 11, 2024 22:03

Ensure QUAY_REGISTRY variable default is set in all scenarios

76d1349

Specify the correct quay_registry variable

945bc53

remove unneded references of the QUAY_REGISTRY env var

c908d97

Add missing slash

1cecc17

Correctly reference tag with env.TAG_NAME

c907495

rooftopcellist merged commit 7992cf0 into ansible:main Jan 12, 2024

rooftopcellist mentioned this pull request Apr 9, 2024

Build a Release workflow #102

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Release Workflow and Single Command Install artifact #159

Add Release Workflow and Single Command Install artifact #159

rooftopcellist commented Jan 4, 2024 •

edited

Loading

rooftopcellist commented Jan 5, 2024 •

edited

Loading

rooftopcellist commented Jan 6, 2024

rooftopcellist commented Jan 8, 2024

rooftopcellist commented Jan 8, 2024 •

edited

Loading

jon-nfc commented Jan 9, 2024 •

edited

Loading

jon-nfc left a comment

jon-nfc Jan 10, 2024

rooftopcellist Jan 10, 2024

jon-nfc Jan 10, 2024

rooftopcellist Jan 10, 2024

rooftopcellist commented Jan 10, 2024

dsavineau left a comment

rooftopcellist commented Jan 12, 2024

goldyfruit commented Jan 12, 2024


		## Maintainers Docs

		Maintainers of this repo need to carry out releases, triage issues, etc. There are docs for those types of administrative tasks in the `docs/maintainer/` directory.

Add Release Workflow and Single Command Install artifact #159

Add Release Workflow and Single Command Install artifact #159

Conversation

rooftopcellist commented Jan 4, 2024 • edited Loading

rooftopcellist commented Jan 5, 2024 • edited Loading

rooftopcellist commented Jan 6, 2024

rooftopcellist commented Jan 8, 2024

rooftopcellist commented Jan 8, 2024 • edited Loading

jon-nfc commented Jan 9, 2024 • edited Loading

jon-nfc left a comment

Choose a reason for hiding this comment

jon-nfc Jan 10, 2024

Choose a reason for hiding this comment

rooftopcellist Jan 10, 2024

Choose a reason for hiding this comment

jon-nfc Jan 10, 2024

Choose a reason for hiding this comment

rooftopcellist Jan 10, 2024

Choose a reason for hiding this comment

rooftopcellist commented Jan 10, 2024

dsavineau left a comment

Choose a reason for hiding this comment

rooftopcellist commented Jan 12, 2024

goldyfruit commented Jan 12, 2024

rooftopcellist commented Jan 4, 2024 •

edited

Loading

rooftopcellist commented Jan 5, 2024 •

edited

Loading

rooftopcellist commented Jan 8, 2024 •

edited

Loading

jon-nfc commented Jan 9, 2024 •

edited

Loading