-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Lint pr titles #6770
feat: Lint pr titles #6770
Conversation
.github/actions/pr-linting/index.js
Outdated
`🔎 Checking if the title of this PR "${title}" meets the requirements ...` | ||
); | ||
|
||
if ((/^\[?wip\]?/i).test(title)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to validate the PR title's if they are WIP's? I figured for now we just skip but wanted to see other people's opinions
on: | ||
pull_request: | ||
types: [opened, edited, reopened, synchronize] | ||
permissions: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our repo grants read + write
permissions to GITHUB_TOKEN
which seemed to be the issue with GET_BUILD
because we granted write access . I've updated the permissions here so that within this workflow they specifically are read only. Originally, I wanted to leave a comment if the PR title failed to validate, but that would require write access and since it didn't seem necessary, I've left it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine, it'll show up in the job's log and it'd fail the PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should be prepared to fix people's title for them
on: | ||
pull_request: | ||
types: [opened, edited, reopened, synchronize] | ||
permissions: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine, it'll show up in the job's log and it'd fail the PR
- name: Use Node 18 | ||
uses: actions/setup-node@v4 | ||
with: | ||
node-version: '18' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason not to use node 20 like the action?
node 20 will pass yarn install, it's just test-esm which gets hung up on it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no i can update it to use node 20 if it yarn install's fine. i just did node 18 since i know our codebase work with it
.github/actions/pr-linting/index.js
Outdated
core.info('Success'); | ||
} | ||
else { | ||
core.info('PR title validation failed. Please read our PR naming guide to see how to correctly name your PR'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be good to have a link ready to go for where to find the PR naming guide.
also, if it's not that long, maybe just inline it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i plan to update this with a link to a wiki page on github but that hasn't happened yet since i wanted to get the team's feedback on the contents before publishing anything
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please bring up in standup or in otters or setup a meeting to push for consensus on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to try this out :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed that the PR title check can take ~2 minutes with most of it being the install step. Maybe not an issue but what are we installing and can it be cached?
.github/actions/pr-linting/index.js
Outdated
if ((/^\[?wip\]?/i).test(title)) { | ||
core.info('This PR is marked as a WIP. Skipping validation'); | ||
} | ||
else if ((/^(fix|feat|build|chore|docs|test|refactor|ci|localize|bump|revert)(\(([A-Za-z])\w+\))?:/gmi).test(title)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little concerned that some of these feel a bit similar (ci vs build) and/or perhaps too granular (test/refactor/bump/localize feel like they primary are updates done in tandem with larger fixes/features and may not be used too often). Happy to be overruled since I'm not familiar with how other repos handle these classifications, but it feels like maybe some of these could be placed under a generic prefix as part of its scope (e.g. fix(test) or chore(bump), etc) Maybe scope could be generalized and instead contain any supplementary information instead (e.g. fix(RAC, localize) Update ColorPicker intl strings to fix crash)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
happy to start with a large set or a small set and see how it goes, can always update down the line
The merge-base changed after approval.
if [[ "${TITLE,,}" =~ ^\[?\(?wip\]?\)? ]]; then | ||
echo "PR is marked as a WIP. Skipping validation." | ||
exit 0 | ||
elif (echo "${TITLE,,}" | grep -P "^(fix|feat|build|chore|docs|test|refactor|ci|localize|bump|revert)(\(([A-Za-z0-9])+\))?:"); then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tbh my scripting knowledge is at a beginner level so there's probably a better way to handle this...but idea is there...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to give this a try
How is this combining with the explorations that @devongovett was doing? I'd like to know the path we're taking forward |
I guess both work on making our changelog more readable but they don't really interfere with each other. The way I see it for now is that this serves as an interim solution as Devon works on adding changesets. This only runs on the PR after it is made on Github while what Devon is working on is ran (ideally) before pushing a PR. Each PR would contain it's own changeset which would get compiled later as the changelog once we do a release. With changesets, we wouldn't use the commit message on main to generate the changelog like we do now. The reason for linting PR titles right now is because it becomes the commit message on main. So, once the changesets gets released, this PR becomes a bit obsolete because what it solves now will be solved by changesets but in a different way. That said, our commit messages on main will still come from the title of the PR's so I don't think it hurts to lint them even if they won't be used to generate our changelog anymore. It also doesn't take much time to run now so that's not as much of a concern anymore |
The overall goal of this PR is to help improve the process of our release notes. Given that we use the titles of the squash commits on main to generate our changelog, improving the readability of our PR titles will hopefully allows us to spend less time manually fixing the names of each commit. Requiring the use of prefixes in our PR titles will eventually also allow us to automatically categorize the commits into the respective categories (like "Enhancement", "Fixes", "Docs", etc) but for now, will make it, in general, easier to organize our commits manually.
That said, I am aware that for cases where there is only one commit (not including merge commits), GitHub will use the commit message as the title for the squash commit. So this doesn't fix that issue. However, a majority of our PR's are multiple commits where the PR title will be used as the title for the squash commit so hopefully this will still help make release notes a bit easier.
For all outside contributors, this workflow will require our approval to run so that we only run this workflow on trusted code. If we approve the workflow and then the contributor pushes up new code, the workflow will require our reapproval to run again. Regardless if a contributor has contributed before, it will require our approval. This is one of the easiest ways to mitigate any bad actors from attempting to inject any malicious code.
Outside of the PR, I've written up a "PR Naming Guide" which I hope to publish on our Github wiki so that outsider contributors can reference it and understand these new requirements. I will also link that wiki in this PR so that if there is an error, you can click on the failed workflow and there will be a link to take you to the guide. (I have yet to finish writing this guide but that's the vision of it).
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: