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
CI: Move IPsec CI jobs into separate pipelines #26730
Conversation
/test-ci-aks |
/ci-aks |
91e8ba2
to
2f1c931
Compare
/test |
I'm personally against moving the IPSec tests away from the clustermesh workflow, unless there's a strong reason, as it increases the overall maintenance burden and likelihood of drifts. I mean, I perfectly understand the rationale behind doing this change for other workflows, but the goal of the clustermesh ones is to verify that cross-cluster communication works in a variety of scenarios, for different control-plane and datapath configurations. Detailed datapath tests are expected to be performed in other workflows (such as conformance E2E) as at the end of the day remote nodes are treated pretty much in the same way as the local ones. |
2f1c931
to
7d3e58d
Compare
@jschwinger233 Did you test the two changed workflows? You might want to reopen this with a branch on cilium/cilium if you haven't already. |
- name: Set Environment Variables | ||
uses: ./.github/actions/set-env-variables | ||
|
||
- name: Set up job variables |
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 we could benefit from https://docs.github.com/en/actions/using-workflows/reusing-workflows to avoid the same code in ci-e2e, ci-ipsec and upcoming ci-upgrade?
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 don't think we should block an improvement on making it a bigger improvement. Let's ship this and iterate after.
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.
Agree with Paul. Let me figure out how to make good use of reusing-workflows for #26983 after.
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.
Yeah, we can do it as a follow-up.
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.
Pending Martynas's suggestion
IPsec cases are moved from conformance-e2e.yaml to conformance-ipsec-e2e.yaml, we can trigger the latter one using /ci-ipsec-e2e. Signed-off-by: Zhichuan Liang <gray.liang@isovalent.com>
7d3e58d
to
e89f149
Compare
Two effected workflows ( |
Only ci-e2e and ci-ipsec-e2e matter. Since both tests are green, I labelled this PR as ready-to-merge. |
This PR moves IPsec test cases from
conformance-e2e.yaml
toconformance-ipsec-e2e.yaml
. It would be beneficial to separate the IPsec test from normal ones as we will have more test specific for IPsec (e.g. #26350 ) and more IPsec features.Signed-off-by: Zhichuan Liang gray.liang@isovalent.com