add workflows for publishing operators and publishing the Developer Sandbox UI for UI E2E testing #149
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,53 @@ | ||
| name: 'Publish Current Toolchain Operators (Host & Member) for UI e2e Tests' | ||
| description: 'An action that publishes the current version of Toolchain Operators as single releases for UI e2e Tests' | ||
| inputs: | ||
| quay-token: | ||
| description: Quay token | ||
| required: true | ||
| quay-namespace: | ||
| description: Quay namespace | ||
| required: false | ||
| default: codeready-toolchain | ||
| sha: | ||
| description: PR head sha | ||
| default: ${{ github.event.pull_request.head.sha }} | ||
| required: false | ||
| pr-number: | ||
| description: Number of the PR | ||
| default: ${{ github.event.pull_request.number }} | ||
| required: false | ||
| author: | ||
| description: Author of the PR | ||
| default: ${{ github.event.pull_request.head.user.login }} | ||
| required: false | ||
| gh-head-ref: | ||
| description: Branch name the PR was opened from | ||
| default: ${{ github.event.pull_request.head.ref }} | ||
| required: false | ||
| runs: | ||
| using: "composite" | ||
| steps: | ||
| - name: Login to quay | ||
| shell: bash | ||
| run: | | ||
| set -e | ||
| export XDG_RUNTIME_DIR=/run/user/${UID} | ||
| mkdir -p ${XDG_RUNTIME_DIR}/containers || true | ||
| echo "{ | ||
| \"auths\": { | ||
| \"quay.io\": { | ||
| \"auth\": \"${{ inputs.quay-token }}\" | ||
| } | ||
| } | ||
| }"> ${XDG_RUNTIME_DIR}/containers/auth.json | ||
|
|
||
| podman login --get-login quay.io | ||
|
|
||
| - name: Publish current bundle for UI e2e Tests | ||
| shell: bash | ||
| run: | | ||
| PROVIDED_REF=${{ inputs.gh-head-ref }} | ||
| if [[ -n ${PROVIDED_REF} ]]; then | ||
| GH_HEAD_REF_PARAM="GITHUB_HEAD_REF=${PROVIDED_REF}" | ||
| fi | ||
| make publish-current-bundles-for-e2e QUAY_NAMESPACE=${{ inputs.quay-namespace }} IMAGE_BUILDER=podman PULL_PULL_SHA=${{ inputs.sha }} PULL_NUMBER=${{ inputs.pr-number }} AUTHOR=${{ inputs.author }} ${GH_HEAD_REF_PARAM} ENVIRONMENT=ui-e2e-tests | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,53 @@ | ||
| name: 'Publish Current Developer Sandbox UI' | ||
| description: 'An action that publishes the current version of Developer Sandbox UI' | ||
|
Comment on lines
+1
to
+2
Collaborator
There was a problem hiding this comment. in which repos will we run this action? In all where we run e2e tests or only in e2e and UI repo?
Contributor
Author
There was a problem hiding this comment. For now, just in toolchain-e2e. When we move the UI code to our own repo, we will run it there too. Regarding host-operator, member-operator, and registration-service, we need to decide if we want to run them. In my opinion, i think it makes sense to run them there too. But first we need to check how stable the ui e2e tests will be on toolchain-e2e and ui repo.
Collaborator
There was a problem hiding this comment. ok, the reason why I asked was if we need another composite/GHA or if it can be part of the already existing build & push process.
Contributor
Author
There was a problem hiding this comment. Deal, I will do on toolchain-e2e pr side to add the workflow directly: https://github.com/codeready-toolchain/toolchain-e2e/pull/1181/files |
||
| inputs: | ||
| quay-token: | ||
| description: Quay token | ||
| required: true | ||
| quay-namespace: | ||
| description: Quay namespace | ||
| required: false | ||
| default: codeready-toolchain | ||
| sha: | ||
| description: PR head sha | ||
| default: ${{ github.event.pull_request.head.sha }} | ||
| required: false | ||
| pr-number: | ||
| description: Number of the PR | ||
| default: ${{ github.event.pull_request.number }} | ||
| required: false | ||
| author: | ||
| description: Author of the PR | ||
| default: ${{ github.event.pull_request.head.user.login }} | ||
| required: false | ||
| gh-head-ref: | ||
| description: Branch name the PR was opened from | ||
| default: ${{ github.event.pull_request.head.ref }} | ||
| required: false | ||
| runs: | ||
| using: "composite" | ||
| steps: | ||
| - name: Login to quay | ||
| shell: bash | ||
| run: | | ||
| set -e | ||
| export XDG_RUNTIME_DIR=/run/user/${UID} | ||
| mkdir -p ${XDG_RUNTIME_DIR}/containers || true | ||
| echo "{ | ||
| \"auths\": { | ||
| \"quay.io\": { | ||
| \"auth\": \"${{ inputs.quay-token }}\" | ||
| } | ||
| } | ||
| }"> ${XDG_RUNTIME_DIR}/containers/auth.json | ||
|
|
||
| podman login --get-login quay.io | ||
|
|
||
| - name: Publish current Developer Sandbox UI | ||
| shell: bash | ||
| run: | | ||
| PROVIDED_REF=${{ inputs.gh-head-ref }} | ||
| if [[ -n ${PROVIDED_REF} ]]; then | ||
| GH_HEAD_REF_PARAM="GITHUB_HEAD_REF=${PROVIDED_REF}" | ||
| fi | ||
| make push-sandbox-plugin QUAY_NAMESPACE=${{ inputs.quay-namespace }} IMAGE_BUILDER=podman PULL_PULL_SHA=${{ inputs.sha }} PULL_NUMBER=${{ inputs.pr-number }} AUTHOR=${{ inputs.author }} GITHUB_BRANCH="${PROVIDED_REF}" ${GH_HEAD_REF_PARAM} | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
why do we need this special GHA composite? and why do we need to provide the
ENVIRONMENTas part of "building & publishing" the bundles? There was probably some change that I missedThere 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.
Since we will have two jobs (one for running our current e2e tests and another to run the ui e2e tests), we need to deploy the operators twice. So, I created a different GHA composite for us to be able to publish a image just for the ui e2e tests. I passed the environment to be able to choose the image name, I was working on this proposed solution: https://github.com/codeready-toolchain/toolchain-e2e/pull/1180/files#diff-569b46caefde16d54d39745e2b26b2e9c19570d97da1e8f4471a587610e5961dR118
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.
ok, this PR is what I was missing codeready-toolchain/toolchain-e2e#1180
TBH, passing environment variable as part of building process is a bit weird. The built images should be environment agnostic, the environment is defined as part of the deployment.
Anyway, I wouldn't create a copy of the already existing composite that differs only in one parameter - let's update the existing and add any parameter we need and that will be set only in the case when it's needed (UI tests)
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.
but wait a sec, why do we actually need to build the bundle & index images for UI tests? there is no pairing with any of the related repos - we can always use the latest index image for UI tests, right?
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 mean at least in the first phase when the tests will be executed separately, or am I missing some small detail?
Uh oh!
There was an error while loading. Please reload this page.
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.
"Confusing" just in terms for us to keep in mind that the ui e2e tests job will deploy the latest operators and not doing pairing
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.
Maybe I am complicating this first phase, sorry!
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 be sorry about that, it's most likely just me who is slow with understanding the final idea 😅 That's why I'm asking these questions 🙂
So what you are saying is that you wanted to enable pairing with reg-service, host-operator, and member-operator PRs from toolchain-e2e for UI tests, right? in other words:
At the same time:
Now I understand your point that we cannot simply rely on the latest version of the operators, because it would break the first case.
But for now, we won't run e2e tests in the RHDH-plugins repo, correct? It will be executed only in toolchain-e2e repo. It looks very similar to what we have for ksctl.
This means that we can rely on the already built operator bundles & images from the already existing GHA workflow https://github.com/codeready-toolchain/toolchain-e2e/blob/master/.github/workflows/publish-operators-for-e2e-tests.yml
in other words, use the same index image in the CatalogSources as we use in the current openshift-ci job for k8s API tests.
Does it cover the case?
Uh oh!
There was an error while loading. Please reload this page.
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.
Correct! For now, we will only run on toolchain-e2e repo.
Unfortunately, no, because we need to configure the ToolchainConfig: https://github.com/codeready-toolchain/toolchain-e2e/blob/master/deploy/host-operator/ui-e2e-tests/toolchainconfig.yaml, so we would need to publish the image for ui e2e tests anyway
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.
Let me rephrase everything, sorry. I struggle to explain myself.
So, since we need to configure the ToolchainConfig: https://github.com/codeready-toolchain/toolchain-e2e/blob/master/deploy/host-operator/ui-e2e-tests/toolchainconfig.yaml, because of the SSO, we would need to publish the operators for ui e2e tests environment.
That's why I added a new GHA workflow, for us to publish a dedicated ui e2e tests images for host and member operators. I agree that we can reuse the current one instead of duplicating, i will address that.
So, in this first phase, we will enable the UI E2E testing only on toolchain-e2e repo, making available the pairing with host-operator, member-operator, registration-service, and RHDH plugin repo. So, if:
there is host-operator PR and toolchain-e2e PR, we need to pair these two PRs so it uses:
there is RHDH-plugins PR and there is toolchain-e2e PR, we need to pair these two PRs so it uses: