DAT-12576 update release workflow to attach artifact by run_id

[ap-liquibase]

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

A clear and concise description of the change being made.

• Introduce what was/will be done in the title
  • Titles show in release notes and search results, so make them useful
  • Use verbs at the beginning of the title, such as "fix", "implement", "improve", "update", and "add"
  • Be specific about what was fixed or changed
  • Good Example: Fix the --should-snapshot-data CLI parameter to be preserved when the --data-output-directory property is not specified in the command.
  • Bad Example: Fixed --should-snapshot-data
• If there is an existing issue this addresses, include "Fixes #XXXX" to auto-link the issue to this PR
• If there is NOT an existing issue, consider creating one.
  • In general, issues describe wanted change from an end-user perspective and PRs describe the technical change.
  • If this change is very small and not worth splitting off an issue, include Steps To Reproduce, Expected Behavior, and Actual Behavior sections in this PR as you would have in the issue.
• Describe what users need and how the fix will affect them
• Describe how the code change addresses the problem
• Ensure private information is redacted.

Things to be aware of

• Describe the technical choices you made
• Describe impacts on the codebase

Things to worry about

• List any questions or concerns you have with the change
• List unknowns you have

Additional Context

Add any other context about the problem here.

[jnewton03]

@ap-liquibase do we need to set a default value for runId ?

[ap-liquibase]

setting a default value would be desirable. I will check with @XDelphiGrl to see what might be a good value for this.

[XDelphiGrl]

setting a default value would be desirable. I will check with @XDelphiGrl to see what might be a good value for this.

@jnewton03 and @ap-liquibase, hi -

I do not think there is a way to programmatically chose a sensible default runId. The attach-artifacts job is manually executed and is not unreasonable to expect the person running the workflow come prepared with the runId of the artifacts they want to attach.

Andre and I discussed the possibility of logic to have an either/or for branch and runId, as branch can always default to master. I feel that complexity is unnecessary at this time. Given that using the default branch sometimes chose the incorrect artifacts was the main reason QA submitted this ask, I think just specifying a runId is sufficient.

Andre is going to check to see if we can safely do a dry run of the functionality in this PR. I've asked him to find out where the repo tag happens, as people in the Community do watch for that; if we put a release tag there now, and don't release for a couple of weeks, people will notice. Andre suggested using a non-standard tag so people would know we are testing and then we could just delete the (test) draft release when we've tested the new workflow with runId.

[jnewton03]

@ap-liquibase @XDelphiGrl that sounds like a good plan