Create qswat-reusable-pr-to-workflow-dependency.yml

[rishi-external]

For any workflows that are being running on the PR creation events (mainly on the forked PR's), we are not able to identify the PR on which a particular workflow ran on, this is the actual limitation from the GitHub. so, we are creating this workflow with PR and workflow as an input and uploading this to the GitHub artifacts and latter any point of time, using the GitHub artifacts API and the workflow ID, we can download the required data that we are uploading tin this workflow Reason for adding this workflow:for a particular workflow, QSWAT team required the workflow to PR details for moving the bug/feature related CRs to their respective states in the automation flows.

[ricardosalveti]

@mynameistechno fyi

[mynameistechno]

How will this workflow be referenced in calling workflows? E.g. @v2 or @main?

I'm just wondering about tagging in this repo. When we update the QC Preflights Checks Workflow, we semver tag this repo, and rewrite the floating major version tag (e.g. currently it's v2).

If you plan to also use tags to control which version is pulled, then we might want to have a dedicated repo for this workflow. But if you're ok with using the current major version of @v2 then this might be fine

[rishi-external]

How will this workflow be referenced in calling workflows? E.g. @v2 or @main?

I'm just wondering about tagging in this repo. When we update the QC Preflights Checks Workflow, we semver tag this repo, and rewrite the floating major version tag (e.g. currently it's v2).

If you plan to also use tags to control which version is pulled, then we might want to have a dedicated repo for this workflow. But if you're ok with using the current major version of @v2 then this might be fine

@mynameistechno , here we want to use this workflow as a @main (using the branch directly), this is because if there are any adoh changes required in the flow, then if we are using the tag, we would have to create a new tag and need to update in all the places where we are referring this, so could we refer the workflow with the @Branch instead of the version, once we have a full and final stable flow, we can go with the versions

[mynameistechno]

@mynameistechno , here we want to use this workflow as a @main (using the branch directly), this is because if there are any adoh changes required in the flow, then if we are using the tag, we would have to create a new tag and need to update in all the places where we are referring this, so could we refer the workflow with the @Branch instead of the version, once we have a full and final stable flow, we can go with the versions

What I described with the floating major version accomplishes the same. E.g. users are using "v2". So when we make a minor or patch release, we update v2 tag to point to the latest sha. This is similar to using a branch but is more structured.

Instead of main, what if you had a dedicated release branch, e.g. "qswat-pr-details-release". It's not a good idea to point to main since this is where the latest and potential unstable/untested workflows reside. So, I would first submit a PR to main, once reviewed and merged, you can test "main" with an example repo. Once satisfied, you can raise PR from main to qswat-pr-details-release so everyone gets the latest

[rishi-external]

@mynameistechno , here we want to use this workflow as a @main (using the branch directly), this is because if there are any adoh changes required in the flow, then if we are using the tag, we would have to create a new tag and need to update in all the places where we are referring this, so could we refer the workflow with the @Branch instead of the version, once we have a full and final stable flow, we can go with the versions

What I described with the floating major version accomplishes the same. E.g. users are using "v2". So when we make a minor or patch release, we update v2 tag to point to the latest sha. This is similar to using a branch but is more structured.

Instead of main, what if you had a dedicated release branch, e.g. "qswat-pr-details-release". It's not a good idea to point to main since this is where the latest and potential unstable/untested workflows reside. So, I would first submit a PR to main, once reviewed and merged, you can test "main" with an example repo. Once satisfied, you can raise PR from main to qswat-pr-details-release so everyone gets the latest

@mynameistechno , yes this work for us, so once merge to main, I will test all the possible scenarions as you suggested and I will requst the for teh release branch "qswat-reusable-workflows"

[njjetha]

LGTM

[rishi-external]

LGTM

Thank you very much @mynameistechno for merging and Thank you @njjetha for reviewing 🙂