add workflows for publishing operators and publishing the Developer Sandbox UI for UI E2E testing#149
Conversation
rsoaresd
changed the title
rsoaresd
changed the title
| 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 |
There was a problem hiding this comment.
why do we need this special GHA composite? and why do we need to provide the ENVIRONMENT as part of "building & publishing" the bundles? There was probably some change that I missed
There was a problem hiding this comment.
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.
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.
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.
I mean at least in the first phase when the tests will be executed separately, or am I missing some small detail?
There was a problem hiding this comment.
"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.
Maybe I am complicating this first phase, sorry!
There was a problem hiding this comment.
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:
- there is host-operator PR
- there is e2e-test PR
- we need to pair these two PRs so it uses
- host-operator from the PR
- toolchain-e2e from the PR
- UI from master
At the same time:
- there is RHDH-plugins PR
- there is e2e-test PR
- we need to pair these two PRs so it uses
- operators from master
- toolchain-e2e from the PR
- UI from the RHDH-plugins PR
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?
There was a problem hiding this comment.
But for now, we won't run e2e tests in the RHDH-plugins repo, correct?
Correct! For now, we will only run on toolchain-e2e repo.
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
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.
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:
- host-operator from the PR
- toolchain-e2e from the PR
- UI from master
there is RHDH-plugins PR and there is toolchain-e2e PR, we need to pair these two PRs so it uses:
- operators from master
- toolchain-e2e from the PR
- UI from the RHDH-plugins PR
| name: 'Publish Current Developer Sandbox UI' | ||
| description: 'An action that publishes the current version of Developer Sandbox UI' |
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?
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.
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.
For the simplicity, since it's gonna be executed in e2e repo only for now, you don't need to create a composite but a workflow in toolchain-e2e repo directly. It can be moved to the composite later when we decide where to run it.
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
|
Closing this pr, i understood wrongly, we do not need dedicated operator images for ui e2e tests |
2 participants
Description
The UI E2E test environment is ready in the toolchain-e2e repository (check #1148). To integrate Developer Sandbox UI E2E tests into the toolchain-e2e CI pipeline, we need to implement the publish operators for UI E2E testing, since we need to have dedicated published operators for UI E2E testing because we need a different ToolchainConfig configuration because of the SSO: https://github.com/codeready-toolchain/toolchain-e2e/blob/master/deploy/host-operator/ui-e2e-tests/toolchainconfig.yaml.
So, to not duplicate the current publish-operators-for-e2e-tests, we need to adapt it to also publish operators for UI E2E testing
Related PRs
codeready-toolchain/toolchain-e2e#1180
codeready-toolchain/toolchain-e2e#1181
Issue ticket number and link
SANDBOX-1371