FEDX-1399: Added validate publish to checks #13
Conversation
Security InsightsNo security relevant content was detected by automated scans. Action Items
Questions or Comments? Reach out on Slack: #support-infosec. |
bender-wk
changed the title
.github/workflows/checks.yaml
Outdated
| validate-publish: | ||
| runs-on: ubuntu-latest | ||
| # only run on release pull requests | ||
| if: ${{ startsWith(github.ref, 'refs/head/release') && github.event.sender == 'rmconsole-readonly-wk' }} |
There was a problem hiding this comment.
Is it a guarantee that the sender will be rmconsole-readonly-wk? I thought we had multiple service accounts and that any of them could be involved based on rate limiting availability
There was a problem hiding this comment.
Looks like we have 9 of them: https://github.com/orgs/Workiva/people?query=rmconsole
I guess I thought that readonly was the one that was used for release prs, although, that might be invalid
We could update that to contains(github.event.sender, 'rmconsole'), probably would be a better check
There was a problem hiding this comment.
Maybe we can find a different/better way to identify release PRs? Technically, it's possible and totally valid from RM's perspective to manually create a release PR - as long as it meets a couple of criteria, RM will recognize it as such even if it didn't create the PR.
There was a problem hiding this comment.
Well, from the perspective of gha-dart-oss, we want to validate for any PR that results in a tag
I'm not sure we'd be able to know that without hitting some, probably non-existant, rmconsole api
An alternate idea would be any PR that changes pubspec.yaml#version? would require a bit of introspection into the PR in question though
|
QA +1
🚀 @Workiva/release-management-p 🚢 |
FEDX-1399
Currently its possible to merge a release PR in a state that will fail
dart pub publishThis PR runs a publish validation for only release PRs so we don't get silent errors