-
Notifications
You must be signed in to change notification settings - Fork 260
pipeline testing for azure-ipam/cni-dropgz submodules #1636
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
Conversation
|
validated pipeline tests via manual run: https://dev.azure.com/msazure/One/_build/results?buildId=61311663&view=results unable to run the full submodule pipeline via PR trigger since submodules-pipeline.yaml is not merged to master and does not have access to pipeline secrets (for Docker login) Only testing ipam/dropgz against swifte2e and ciliume2e scenarios. Is there anything else we want to include/exclude in the pipeline? @rbtr |
| pr: | ||
| branches: | ||
| include: | ||
| - master | ||
| paths: | ||
| exclude: | ||
| - ".*" | ||
| - docs | ||
|
|
||
| trigger: | ||
| paths: | ||
| include: | ||
| - "zapai/*" | ||
| - "azure-ipam/*" | ||
| - "dropgz/*" | ||
| exclude: | ||
| - docs | ||
| tags: | ||
| include: | ||
| - "zapai/*" | ||
| - "azure-ipam/*" | ||
| - "dropgz/*" |
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.
for includes to work as intended here, do we need to exclude everything else?
| pr: | |
| branches: | |
| include: | |
| - master | |
| paths: | |
| exclude: | |
| - ".*" | |
| - docs | |
| trigger: | |
| paths: | |
| include: | |
| - "zapai/*" | |
| - "azure-ipam/*" | |
| - "dropgz/*" | |
| exclude: | |
| - docs | |
| tags: | |
| include: | |
| - "zapai/*" | |
| - "azure-ipam/*" | |
| - "dropgz/*" | |
| pr: | |
| branches: | |
| include: | |
| - master | |
| paths: | |
| exclude: | |
| - "*" | |
| include: | |
| - "zapai/*" | |
| - "azure-ipam/*" | |
| - "dropgz/*" | |
| trigger: | |
| paths: | |
| exclude: | |
| - "*" | |
| include: | |
| - "zapai/*" | |
| - "azure-ipam/*" | |
| - "dropgz/*" | |
| tags: | |
| exclude: | |
| - "*" | |
| include: | |
| - "zapai/*" | |
| - "azure-ipam/*" | |
| - "dropgz/*" |
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, this would make more sense
.pipelines/submodules-pipeline.yaml
Outdated
| make tools | ||
| # run test, echo exit status code to fd 3, pipe output from test to tee, which splits output to stdout and go-junit-report (which converts test output to report.xml), stdout from tee is redirected to fd 4. Take output written to fd 3 (which is the exit code of test), redirect to stdout, pipe to read from stdout then exit with that status code. Read all output from fd 4 (output from tee) and write to top stdout | ||
| { { { { | ||
| sudo -E env "PATH=$PATH" make test-all; |
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.
seems too broad
| @@ -0,0 +1,29 @@ | |||
| parameters: | |||
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.
Copy/pasting like this is going to create additional maintenance overhead, and the designs will immediately begin to drift apart. We should evaluate what is actually different between the two pipelines and parameterize the templates accordingly so that they are generic enough to run in both scenarios.
.pipelines/submodules-pipeline.yaml
Outdated
| name: $(name) | ||
| platforms: $(platforms) | ||
|
|
||
| # - template: singletenancy/ipam-dropgz/ipam-dropgz-cilium-e2e-job-template.yaml |
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 see this template commented out, should it be enabled? I couldn't find any other reference to ipam-dropgz-cilium-e2e-job or the swift one
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 commented it out while I was testing a new parameter with the original swifte2e and ciliume2e template. I am planning to remove the ipam-dropgz templates
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'm restructuring things based off of the feedback I've gotten so far
|
* add new ipam/dropgz e2e test stage * set test image * set paths in pipeline.yaml * set path trigger in ipam-dropgz-job template * set path as param for ipam-dropgze2e * testing path trigger with branch * create submodule pipeline * add log in /azure-ipam to test piepline trigger * remove build for cni-dropgz image in submodule pipeline * create separate swift + cilium ipam/dropgz test stages * remove commented test bits * remove commented lines from setup_test.go * update paths/triggers and set template parameters * change cleanup dependsOn * test parameter call * export parameter * skip setting testDropgz instead of setting false * removing ipam-dropgz templates and focus submod UT on azure-ipam * remove parsing gatewayIP from azure-ipam unit tests * update make target test-azure-ipam * update make target * only publish test results * omit npm build * keep npm build and simplify unit testing stage * adjust cluster naming to avoid resource overlap in pipelines
Reason for Change:
Current state of e2e tests changes to dropgz/azure-ipam on every run regardless of whether or not change is present.
Adding submodule pipeline that will only trigger runs if there are changes in the azure-ipam or dropgz directories. This pipeline will test the cni-dropgz-test image.
When changes are not present, the e2e tests will run only on the regular cni-dropgz image, which is built from the cni installer that utilizes released versions of components.
New Submodule Pipeline: https://dev.azure.com/msazure/One/_build?definitionId=292133&_a=summary
Issue Fixed:
Requirements:
Notes: