There's a master branch with product version of e.g. 4.0.0 early preview
There's a tag v3.8.2 of the previously released product
There's a need to release v3.8.3 to address a critical issue that requires a hotfix
There's a single Screwdriver pipeline targeted to a master branch
What I'm trying to do doing:
Checkout a release/v3.8.3 branch from v3.8.2 tag
Add a hotfix commit there
Tag the commit as v3.8.3 release
This launches following sequence of events:
A ~release is triggered on the pipeline
Screwdriver attempts to build old codebase using the newest screwdriver.yaml from the master branch
Needless to say, that is very likely to fail
Another suggested approach would be to create an extra Screwdriver pipeline that's targeted to release/v3.8.3 branch, but in this case making a release will trigger both pipelines, potentially causing broken or conflicting release (at artifactory level). Mentioned release filtering would do the work, if I'll create an extra pipeline AND would alter screwdriver.yaml from release/v3.8.3 branch to target only that release AND would alter screwdriver.yaml from the master branch to ignore v3.8.X release train. I'm not exactly sure that's how this was designed to work in such scenarios, assuming that screwdriver.yaml is always used from master branch
What you expected to happen:
Release & tag events to use screwrdriver.yaml from the git sha of the release or tag
What happened:
Usecase:
What I'm trying to do doing:
This launches following sequence of events:
Another suggested approach would be to create an extra Screwdriver pipeline that's targeted to release/v3.8.3 branch, but in this case making a release will trigger both pipelines, potentially causing broken or conflicting release (at artifactory level). Mentioned release filtering would do the work, if I'll create an extra pipeline AND would alter screwdriver.yaml from release/v3.8.3 branch to target only that release AND would alter screwdriver.yaml from the master branch to ignore v3.8.X release train. I'm not exactly sure that's how this was designed to work in such scenarios, assuming that screwdriver.yaml is always used from master branch
What you expected to happen:
Release & tag events to use screwrdriver.yaml from the git sha of the release or tag
How to reproduce it:
See above.