ci: add twice weekly azure integration test workflows - #6943
Conversation
|
Helpful to have landed pycloudlib/517 |
| workflow_dispatch: | ||
| inputs: | ||
| install_source: | ||
| required: false | ||
| type: string | ||
| default: 'ppa:cloud-init-dev/daily' | ||
| image_type: | ||
| required: true | ||
| type: choice | ||
| options: | ||
| - generic | ||
| - minimal | ||
| filter_tests: | ||
| required: false | ||
| type: string |
There was a problem hiding this comment.
Aren't these workflow_dispatch definitions redundant? Can't we trigger any release/platform combo from the common file directly? Same comment on the other files.
There was a problem hiding this comment.
We can trigger the workflow from the common file, but then that manual workflow dispatch gets associated with pipeline of all platforms and releases gets organized under https://github.com/canonical/cloud-init/actions/workflows/100-dispatch-common.yml. I'd like the ability to have the former manual runs organized under the specific platform and series such as https://github.com/canonical/cloud-init/actions/workflows/120-daily-integration-22.04-lxd_vm.yml. This redudancy buys us the ability to manually kick off 4 azure jobs in parallel for the 4 supported series from the platform&series workflow and ensure that those manual runs retain organization as the most recent build under a given platform/series.
There was a problem hiding this comment.
We can trigger the workflow from the common file, but then that manual workflow dispatch gets associated with pipeline of all platforms and releases gets organized under https://github.com/canonical/cloud-init/actions/workflows/100-dispatch-common.yml.
Are there any advantages to triggering from the common workflow? Can we drop that in favor of triggering from the specific workflows?
This redudancy buys us the ability to manually kick off 4 azure jobs in parallel for the 4 supported series from the platform&series workflow and ensure that those manual runs retain organization as the most recent build under a given platform/series.
It's not the redundancy that buys us that, is it? Isn't the definition in each workflow what enables that organization?
There was a problem hiding this comment.
We definitely can reduce duplication of workflow_dispatch by dropping it from 100-dispatch-common as most manual SRU validation operations should original from a "Run Workflow" on a specific platform/release action page, not the common dispatch page. Thanks for the discussion here. I have dropped the common workflow_dispatch. And successfully triggered a manual workflow for Azure/Jammy as POC
2 participants
Add Azure integration test coverage aligned with release coverage we have in Ec2, lxd_container and lxd_vm.
Proposed Commit Message
Additional Context
Success run on my own remote
Test Steps
Merge type