With skip-push-events-for-pr-commits enabled, do not skip push events generated when tags are pushed

Goals

1. With "skip-push-events-for-pr-commits" enabled and when a Pull Request is open for the source branch, push events for commits are being skipped, since the shaID for the commit is automatically included in the open PR.
2. PR's are expected to be open for sometime, since procedurally someone has to approve it.
3. And in the above scenario, all commits to a branch like feature branch wont result in pipeline runs being kicked and hence developers cannot test their new commits after the PR is open.

The Goal of this RFE is not to skip the push events generated when a tag is pushed for a commit while its SHAID is in an open PR for the source branch.

All Customers benefit from this RFE, as it provides a way to test new commits when a PR is open for the source branch and PR's are typically expected to be open for extended periods.

Requirements

• • With "skip-push-events-for-pr-commits" feature enabled, do not skip the push events generated when a tag is pushed for a commit whose ShaID is in an open PR for the source branch

Out of scope

<Defines what is not included in this story>

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment