Skip to content
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

Align EKB and eventing-core installed versions for e2e tests #1025

Conversation

creydr
Copy link
Member

@creydr creydr commented Mar 15, 2024

Align the installed version of EKB and eventing-core for tests.

Make use of USE_RELEASE_NEXT and make generated-files-release-next from openshift-knative/serverless-operator#2528

Testrun in #1026 and #994

Copy link

openshift-ci bot commented Mar 15, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: creydr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@creydr creydr force-pushed the install-release-next-versions-from-so-when-on-rn-branch branch from ac826a0 to 679967d Compare March 15, 2024 16:39
@creydr
Copy link
Member Author

creydr commented Mar 18, 2024

Testrun on release-v1.12 branch (#994):

Aligned version with branch of EKB (--> used v1.12 for eventing-core):

        {
            "apiVersion": "v1",
            "kind": "Pod",
            "metadata": {
                ...
                "labels": {
                    "app": "eventing-controller",
                    "app.kubernetes.io/component": "eventing-controller",
                    "app.kubernetes.io/name": "knative-eventing",
                    "app.kubernetes.io/version": "v1.12",
                    "pod-template-hash": "84b9ffbd7"
                },
                "name": "eventing-controller-84b9ffbd7-66hxt",

https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift-knative_eventing-kafka-broker/994/pull-ci-openshift-knative-eventing-kafka-broker-release-v1.12-414-test-e2e-aws-414/1769632228553265152/artifacts/test-e2e-aws-414/openshift-gather-extra/artifacts/pods.json

Testrun on release-next branch (#1026):
Installed nightly for eventing-core (see #1026 (comment))

            "kind": "Pod",
            "metadata": {
                "creationTimestamp": "2024-03-15T23:31:25Z",
                "generateName": "eventing-controller-bf99fc574-",
                "labels": {
                    "app": "eventing-controller",
                    "app.kubernetes.io/component": "eventing-controller",
                    "app.kubernetes.io/name": "knative-eventing",
                    "app.kubernetes.io/version": "nightly",
                },
                "name": "eventing-controller-bf99fc574-8hcqw",

@creydr creydr changed the title [WIP] Align EKB and eventing-core installed versions for e2e tests Align EKB and eventing-core installed versions for e2e tests Mar 18, 2024
@creydr
Copy link
Member Author

creydr commented Mar 18, 2024

/cc @matzew @pierDipi

@creydr
Copy link
Member Author

creydr commented Mar 18, 2024

/cc @mgencur

@creydr
Copy link
Member Author

creydr commented Mar 19, 2024

/assign @matzew @pierDipi

@pierDipi
Copy link
Member

@creydr @mgencur in this form, we would only support release next, I believe if we make the branch/version configurable instead of hardcoding release-next in SO ( and default it to use project.yaml configurations) we could leverage it in any branch

@mgencur
Copy link

mgencur commented Mar 25, 2024

@creydr @mgencur in this form, we would only support release next, I believe if we make the branch/version configurable instead of hardcoding release-next in SO ( and default it to use project.yaml configurations) we could leverage it in any branch

Not sure if I understand it correctly. You mean we could use make generated-files instead switching between generated-files-release-next an make generated-files by allowing to pass the branch here in the form of ENV variable?
Something like KNATIVE_EVENTING_KAFKA_BROKER_BRANCH=release-next make generated-files ?

Note: This would need specifying the branch for all components, i.e. KNATIVE_SERVING_BRANCH=release-next KNATIVE_EVENTING_BRANCH=release-next KNATIVE_EVENTING_KAFKA_BROKER_BRANCH=release-next make generated-files

@creydr
Copy link
Member Author

creydr commented Apr 2, 2024

In this PR we would only install the release-next artifacts, when on the release-next branch. Otherwise the artifacts of the coresponding release-vX.Y branch will be installed (see

if [ "$ekb_branch" = "release-next" ]; then
export USE_RELEASE_NEXT="true"
make generated-files-release-next
else
# use same eventing-core version as for EKB
yq w --inplace "${operator_dir}/olm-catalog/serverless-operator/project.yaml" 'dependencies.eventing' "${ekb_tag}"
yq w --inplace "${operator_dir}/olm-catalog/serverless-operator/project.yaml" 'dependencies.eventing_artifacts_branch' "${ekb_branch}"
make generated-files
fi
).

Anyhow we discussed that something like this would make more sense to have it directly in SO, so we don't need to repeat it in every repo. So closing this here

@creydr creydr closed this Apr 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants