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

Automate creation of Issue for major release PHP synchronisation #57890

Merged
merged 22 commits into from
Jan 19, 2024

Conversation

getdave
Copy link
Contributor

@getdave getdave commented Jan 16, 2024

What?

Automates the creation of the contents for the Issue that tracks PHP changes (example) that may need to be synchronised to WP Core for a major release.

Why?

For a major release, the Editor Tech Lead needs to create an Issue like this one which details all the PHP changes that may need backport to Core.

This requires manually going through all the key directories in the project that may contain PHP changes and then checking all the PRs that have been merged since the final RC of the previous release. If any PRs contain PHP changes then the PR needs to be added to the Issue in a very specific format.

It also requires organising headings for each seciton and doing a lot of manual formatting.

All this is:

  • laborious - I'm told it typically requires a full day or more to complete
  • prone to error - it's easy to make a typo or miss a change

This is why I think it's wide open for automation.

How?

This PR has a script which can be run locally which will

  • get all commits to trunk in a number of key directories (including /lib, /block-library and /phpunit) since a date you provide.
  • get the details for each of the commits including the files that were changed
  • put the commit under the correct heading based on which files were changed
  • dedupe the result set
  • output the markdown required to create the Issue

I've made some subjective choices about how things are group and displayed:

  • PRs may be listed only once in the Issue - the exception is PRs which modify PHP Unit tests as I wanted to display a full list of changes that affect the /phpunit directory. Actually PRs are allowed more than once as long as it's across different sections
  • No more than 3 level of nesting - anything beyond that gets very visually messy. I've grouped PRs that would appear under those subheadings under the third level of nesting.
  • Certain directories are excluded including e2e-tests and experiments-page.php which are never synchronised - please feel free to suggest additions to that list.
  • I've elected to avoid the additional network requests required to fetch the details of the PRs associated with each commit. Instead I've used regex to attempt to build the PR URL from the commit message. This isn't 100% reliable but it works in the majority of cases and we have a reasonable fallback in place.

Testing Instructions

  • Get GH Personal Access Token
  • Run node bin/generate-php-sync-issue.mjs --token={YOUR_TOKEN_HERE} --since=2023-11-01
  • Open issueContent.md and copy all contents.
  • Go to https://github.com/WordPress/gutenberg/issues/new/ and paste contents.
  • Preview the Issue - DO NOT SUBMIT IT!
  • Take any given PR in the Issue and check that the files it modified match up with where it is listed in the Issue.

Testing Instructions for Keyboard

Screenshots or screencast

const content = generateIssueContent( result );

// Write the Markdown content to a file
fs.writeFileSync( nodePath.join( __dirname, 'issueContent.md' ), content );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently writes to a file. We could have it automatically create the Issue on Github.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this, since the generated content will almost certainly need a bit of editing. Might just be easier to write to file and the person generating it can copy/paste/edit before publishing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds fine to me. It's a very manual script anyway. The overhead of auto-creating an Issue probably isn't worth the effort.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we shouldn't create an issue but we could actually output the content in the console. So the commands become something like yourcommand > issueContent.md if you really want to put the content in a file. That seems more inline with how tools like that work.

Comment on lines 404 to 413
// The paginate method will fetch all pages of results from the API.
// We limit the total results because we only fetch commits
// since a certain date (via the "since" param).
commits = await octokit.paginate( 'GET /repos/{owner}/{repo}/commits', {
owner,
repo,
since,
per_page: 100,
path,
} );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can generate a fair number of requests

owner,
repo,
since,
path
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not using path will result in a tonne of commits that have little or no value. So actually it's better to only fetch commits against the paths we know will have PHP files that need to be synced.

Comment on lines +147 to +148
? `https://github.com/WordPress/gutenberg/pull/${ prId }`
: `[Commit](${ commit.html_url })`;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can't build the PR URL from the commit message, then we'll fall back to the commit URL itself and let GH UI show the link to the PR there.

@getdave getdave self-assigned this Jan 17, 2024
@getdave getdave added the [Type] Project Management Meta-issues related to project management of Gutenberg label Jan 17, 2024
@getdave getdave changed the title [WIP] Release automation testing Automate creation of Issue for major release PHP synchronisation Jan 17, 2024
@getdave getdave requested review from annezazu and priethor January 17, 2024 09:56
@getdave getdave marked this pull request as ready for review January 17, 2024 10:06
@getdave getdave requested a review from Mamaduka January 17, 2024 10:06
@Mamaduka
Copy link
Member

I believe @ramonjd was working on something similar last year.

@getdave getdave requested a review from ramonjd January 17, 2024 10:33
Copy link
Contributor

@tellthemachines tellthemachines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, this is working pretty well for me!

Regarding the generated content:

  • the compat/wordpress-6.4 folder can be removed, since whatever is in there is already in core. It exists to provide compatibility for WP 6.3, because we have to support the current and the previous WP versions. Not sure if there's a simple way to automate that as the folder numbers will vary per release - might be easier to just delete it manually.
  • load.php is plugin-specific so we probably don't need to look at it either.
  • not sure if this is possible: could we remove some PRs from the list if they have a certain label? Anything with Backport from WordPress Core can safely be ignored.
  • Would it be worth checking the Needs PHP backport label and including any PRs from there that aren't in the list?

One thing to bear in mind is that we should include all PRs since the last plugin release to be fully included in Beta 1, because anytime after that new features could have been merged that would still need syncing. See my comment on validateSince below 😄

Other than that I think this is looking pretty good! I'm no node expert though so you might want a second opinion on the code itself.

bin/generate-php-sync-issue.mjs Outdated Show resolved Hide resolved
bin/generate-php-sync-issue.mjs Show resolved Hide resolved
const content = generateIssueContent( result );

// Write the Markdown content to a file
fs.writeFileSync( nodePath.join( __dirname, 'issueContent.md' ), content );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this, since the generated content will almost certainly need a bit of editing. Might just be easier to write to file and the person generating it can copy/paste/edit before publishing.

bin/generate-php-sync-issue.mjs Outdated Show resolved Hide resolved
Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great to me. Some valid remarks above from @tellthemachines but otherwise it's a perfect head start to the backporting process. Nice work everyone.

@getdave
Copy link
Contributor Author

getdave commented Jan 18, 2024

Thanks for review @tellthemachines 👍

  • the compat/wordpress-6.4 folder can be removed, since whatever is in there is already in core. It exists to provide compatibility for WP 6.3, because we have to support the current and the previous WP versions. Not sure if there's a simple way to automate that as the folder numbers will vary per release - might be easier to just delete it manually.

Currently it will remove the folder for the current stable release but I think we need to make it a whitelist to retain only the folder for the next release and remove all others.

  • load.php is plugin-specific so we probably don't need to look at it either.

✅ Done

  • not sure if this is possible: could we remove some PRs from the list if they have a certain label? Anything with Backport from WordPress Core can safely be ignored.

Apparently this label gets removed once the PR has been backported as a way of indicating it's completion status. So instead @youknowriad and I agreed that we would flag any PRs made between Beta 1 and final RC with a special warning.

  • Would it be worth checking the Needs PHP backport label and including any PRs from there that aren't in the list?

Yes that would be a nice addition.

One thing to bear in mind is that we should include all PRs since the last plugin release to be fully included in Beta 1, because anytime after that new features could have been merged that would still need syncing. See my comment on validateSince below 😄

--since will work with whatever you provide. I've extended the max allowed date.

@getdave
Copy link
Contributor Author

getdave commented Jan 18, 2024

Given that this is not production code we could probably look to merge and iterate on this.

@youknowriad
Copy link
Contributor

not sure if this is possible: could we remove some PRs from the list if they have a certain label? Anything with Backport from WordPress Core can safely be ignored.

@getdave "from WordPress Core" is another label and these can be safely ignored regardless of date...

@ramonjd
Copy link
Member

ramonjd commented Jan 18, 2024

I believe @ramonjd was working on something similar last year.

Thanks for the ping. I had a local shell script trying to do what this PR's script does, but mine was definitely not as good and detailed as this one, and required too much manual clean up. Thanks for this initiative @getdave!

Copy link
Contributor

@tellthemachines tellthemachines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Small non-blocking typo and comment below. I think we can merge and iterate.

bin/generate-php-sync-issue.mjs Outdated Show resolved Hide resolved
Copy link
Member

@Mamaduka Mamaduka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent work, Dave.

Maybe, as a follow-up, we can document the usage of this script. Here is an example of cherry-picking automation docs - https://developer.wordpress.org/block-editor/contributors/code/release/auto-cherry-picking/.

@getdave
Copy link
Contributor Author

getdave commented Jan 19, 2024

  • Backport from WordPress Core

✅ I've set up an ignore list for any labels. This can be added to in followups.

@getdave getdave enabled auto-merge (squash) January 19, 2024 10:10
@getdave
Copy link
Contributor Author

getdave commented Jan 19, 2024

Just noting I used this script to generate #57959

@getdave getdave merged commit b716ae3 into trunk Jan 19, 2024
54 of 55 checks passed
@getdave getdave deleted the try/automate-php-synchronisation-issue-template branch January 19, 2024 10:40
@github-actions github-actions bot added this to the Gutenberg 17.6 milestone Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Project Management Meta-issues related to project management of Gutenberg
Projects
Development

Successfully merging this pull request may close these issues.

6 participants