Have OpenAI's Codex suggest commit messages#1984
Conversation
|
Suggested commit message: Edit by Stephan: This comment was posted before I updated the marker string. Hence the second bot-generated comment further down. As you can see, that one has been edited by the bot quite a number of times. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Suggested commit message: |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
9183931 to
68d7834
Compare
|
Looks good. No mutations were possible for these changes. |
4 similar comments
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
| 6. For dependency upgrades in particular, *very precisely* follow the pattern of past commit messages: reuse the summary wording (only adjust version numbers) and list updated changelog, release note, and diff URLs in the body. | ||
| 7. Don't hallucinate URLs, version numbers, or other factual information. | ||
| 8. Never split URLs across multiple lines, even if they exceed 72 characters. | ||
| 9. If the pull request description already contains a suitable commit message, prefer using that as-is. |
There was a problem hiding this comment.
| 9. If the pull request description already contains a suitable commit message, prefer using that as-is. | |
| 9. If the pull request description already contains a suitable commit message, consider using that as-is or as an inspiration for your generated message. |
| 7. Don't hallucinate URLs, version numbers, or other factual information. | ||
| 8. Never split URLs across multiple lines, even if they exceed 72 characters. | ||
| 9. If the pull request description already contains a suitable commit message, prefer using that as-is. | ||
|
|
There was a problem hiding this comment.
| 11. Finally, consider adding a small description of work that is not relevant to the main PR changes, on a separate line as part of the commit message body, starting with "While here, " phrase. (i.e, "While here, fixed a typo in variable name.") |
There was a problem hiding this comment.
I fear that this will yield very low signal to noise; already I found the non-upgrade commit summaries "okay, not great". I'll think of a different way of phrasing this, but may leave it out; TBD.
| Requirements: | ||
| 1. Write the summary line in the imperative mood. Try not to exceed 80 characters. | ||
| 2. End the summary line with the PR number in parentheses, i.e., " (#${prNumber})". | ||
| 2. Wrap each body paragraph at 72 characters. Focus on the "what" and "why" rather than implementation details. |
There was a problem hiding this comment.
| 2. Wrap each body paragraph at 72 characters. Focus on the "what" and "why" rather than implementation details. | |
| 2. Wrap each body paragraph at 72 characters. Focus on the "what" and "why" rather than implementation details. Unlike summary lines, message bodies are complete sentences that should end with a full stop. |
| 2. End the summary line with the PR number in parentheses, i.e., " (#${prNumber})". | ||
| 2. Wrap each body paragraph at 72 characters. Focus on the "what" and "why" rather than implementation details. |
There was a problem hiding this comment.
😄
| 2. End the summary line with the PR number in parentheses, i.e., " (#${prNumber})". | |
| 2. Wrap each body paragraph at 72 characters. Focus on the "what" and "why" rather than implementation details. | |
| 2. End the summary line with the PR number in parentheses, i.e., " (#${prNumber})". | |
| 3. Wrap each body paragraph at 72 characters. Focus on the "what" and "why" rather than implementation details. |
Stephan202
left a comment
There was a problem hiding this comment.
Tnx for the review @mohamedsamehsalah! I'll circle back to this later, when I combine your suggestions and do some more tests.
| 7. Don't hallucinate URLs, version numbers, or other factual information. | ||
| 8. Never split URLs across multiple lines, even if they exceed 72 characters. | ||
| 9. If the pull request description already contains a suitable commit message, prefer using that as-is. | ||
|
|
There was a problem hiding this comment.
I fear that this will yield very low signal to noise; already I found the non-upgrade commit summaries "okay, not great". I'll think of a different way of phrasing this, but may leave it out; TBD.
rickie
left a comment
There was a problem hiding this comment.
Already saw some nice feedback from @mohamedsamehsalah . This looks really nice. Amazing way to use AI to automate some of the things we have to do!
| Some further guidelines to help you craft good upgrade commit messages: | ||
| - Unless highly salient, don't summarize code changes made as part of the upgrade. | ||
| - Don't bother linking to anchors within changelogs or release notes; just link to the main page. | ||
| - For GitHub-hosted projects, always link to all relevant GitHub release pages, including those for intermediate versions. |
There was a problem hiding this comment.
| - For GitHub-hosted projects, always link to all relevant GitHub release pages, including those for intermediate versions. | |
| - For GitHub-hosted projects, always link to all relevant GitHub release pages, including those for intermediate versions, like milestones. |
I know we mean that with intermediate versions, but noticed that the milestones from Spring were not added 🤔. So maybe we nudge it slightly more?
There was a problem hiding this comment.
See the sentence below... 🙃. This doesn't help, apparently.
| id: prompt | ||
| uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0 | ||
| env: | ||
| PR_NUMBER: ${{ steps.pr-details.outputs.number }} |
There was a problem hiding this comment.
| PR_NUMBER: ${{ steps.pr-details.outputs.number }} | |
| REPOSITORY: ${{ github.repository }} | |
| PR_NUMBER: ${{ steps.pr-details.outputs.number }} |
| return `${truncated}\n... (${limit} of ${lines.length} lines shown)`; | ||
| }; | ||
|
|
||
| const env = process.env; |
There was a problem hiding this comment.
| const env = process.env; | |
| const env = process.env; | |
| const repository = env.REPOSITORY; |
| const cleanedBody = (body || '').trim() || '<no pull request description>'; | ||
|
|
||
| const instructions = ` | ||
| You are an experienced maintainer helping to craft the squash commit message for PR #${prNumber} in the PicnicSupermarket/error-prone-support repository. |
There was a problem hiding this comment.
| You are an experienced maintainer helping to craft the squash commit message for PR #${prNumber} in the PicnicSupermarket/error-prone-support repository. | |
| You are an experienced maintainer helping to craft the squash commit message for PR #${prNumber} in the ${repository} repository. |
This new GitHub Actions workflow upserts a pull request comment any time the PR is updated, to suggest an appropriate commit message for the squash-and-merge workflow. The workflow can also be triggered manually to simplify testing.
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
Looks good. No mutations were possible for these changes. |
|
|
I tweaked a few things. Some aspects are still hit-or-miss. But will merge now to officially wrap this up. |




Suggested commit message:
I tested part of this PR by temporarily changing the default branch (necessary because the new workflow doesn't exist on
masteryet) and running e.g.:Examples of generated commit messages:
This PR was largely created using Windsurf with the
GPT-5-Codexmodel, with tweaks from my side.