Skip to content
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

Merged
merged 13 commits into from
Oct 15, 2024
Merged

feat: Lint pr titles #6770

merged 13 commits into from
Oct 15, 2024

Conversation

yihuiliao
Copy link
Member

@yihuiliao yihuiliao commented Jul 25, 2024

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:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

@rspbot
Copy link

rspbot commented Jul 25, 2024

`🔎 Checking if the title of this PR "${title}" meets the requirements ...`
);

if ((/^\[?wip\]?/i).test(title)) {
Copy link
Member Author

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:
Copy link
Member Author

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.

Copy link
Member

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

@adobe adobe deleted a comment from rspbot Jul 26, 2024
Copy link
Member

@snowystinger snowystinger left a 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:
Copy link
Member

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'
Copy link
Member

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

Copy link
Member Author

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

core.info('Success');
}
else {
core.info('PR title validation failed. Please read our PR naming guide to see how to correctly name your PR');
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

@snowystinger snowystinger left a 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.

@yihuiliao yihuiliao marked this pull request as ready for review August 22, 2024 20:27
@yihuiliao yihuiliao changed the title wip: Lint pr titles feat: Lint pr titles Aug 22, 2024
snowystinger
snowystinger previously approved these changes Aug 22, 2024
Copy link
Member

@snowystinger snowystinger left a 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 :)

Copy link
Member

@LFDanLu LFDanLu left a 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?

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)) {
Copy link
Member

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)

Copy link
Member

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

@rspbot
Copy link

rspbot commented Aug 22, 2024

reidbarber
reidbarber previously approved these changes Aug 22, 2024
@rspbot
Copy link

rspbot commented Oct 2, 2024

@rspbot
Copy link

rspbot commented Oct 2, 2024

@yihuiliao yihuiliao changed the title feat: Lint pr titles feat: Lint pr titles test Oct 2, 2024
@rspbot
Copy link

rspbot commented Oct 2, 2024

@rspbot
Copy link

rspbot commented Oct 2, 2024

@yihuiliao yihuiliao changed the title feat: Lint pr titles test feat: Lint pr titles Oct 2, 2024
@rspbot
Copy link

rspbot commented Oct 3, 2024

@yihuiliao yihuiliao changed the title feat: Lint pr titles feat: Lint pr titles test Oct 3, 2024
@rspbot
Copy link

rspbot commented Oct 3, 2024

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
Copy link
Member Author

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...

@yihuiliao yihuiliao changed the title feat: Lint pr titles test feat: Lint pr titles Oct 3, 2024
@rspbot
Copy link

rspbot commented Oct 3, 2024

Copy link
Member

@LFDanLu LFDanLu left a 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

@snowystinger
Copy link
Member

How is this combining with the explorations that @devongovett was doing? I'd like to know the path we're taking forward

@yihuiliao
Copy link
Member Author

yihuiliao commented Oct 14, 2024

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

@yihuiliao yihuiliao added this pull request to the merge queue Oct 15, 2024
Merged via the queue into main with commit ce87249 Oct 15, 2024
31 checks passed
@yihuiliao yihuiliao deleted the lint-pr-titles branch October 15, 2024 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants