Description
Running multiple instances of the same module validation workflow, may result in conflicts when trying, e.g., to deploy resources while the same resources are getting deleted by a previous run.
concurrency can be enabled at workflow (Ref: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency) or job level (Ref: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency) to ensure that only a single workflow or job using the same concurrency group will run at a time.
In the default behavior, next runs are queued and started as soon as previous runs complete.
Alternatively, the cancel-in-progress setting can be used to cancel previous runs, triggering the most recent instead. This setting does not look useful in the CARML case, since canceling e.g. the deployment validation job, would not cancel the actual test deployment to Azure, resulting anyway in the same deployment conflicts described above.
This issue is about implementing a PoC to add concurrency to GH module validation workflows, proposing, e.g.,
- On which level (workflow vs job) concurrency should be enabled
- What would be the most convenient group to set up
Description
Running multiple instances of the same module validation workflow, may result in conflicts when trying, e.g., to deploy resources while the same resources are getting deleted by a previous run.
concurrencycan be enabled at workflow (Ref: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency) or job level (Ref: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency) to ensure that only a single workflow or job using the same concurrency group will run at a time.In the default behavior, next runs are queued and started as soon as previous runs complete.
Alternatively, the
cancel-in-progresssetting can be used to cancel previous runs, triggering the most recent instead. This setting does not look useful in the CARML case, since canceling e.g. the deployment validation job, would not cancel the actual test deployment to Azure, resulting anyway in the same deployment conflicts described above.This issue is about implementing a PoC to add concurrency to GH module validation workflows, proposing, e.g.,