Proposal: automate workflow with GitHub Actions

[lucasbento]

Introduction

This is a proposal to automate the workflow of generating diffs (for rn-diff-purge and upgrade-helper) when creating new releases, work that's currently relying solely on @pvinis.

The Core of It

This proposal is to automate all the manual process with GitHub Actions, here's how we can do it:

In react-native main repository

1. Add a small GitHub Action to the main react-native repo to trigger a dispatch_event on new tags to @react-native-community/rn-diff-purge, this should also carry over the tag version, example of this can be seen here.

In rn-diff-purge

1. Get the version param from the dispatch event in a GitHub Action;
2. Create a branch (e.g. 0.62.0-rc.5) and push it (should be done on top of the last release branch);
3. Create and checkout to a staging branch (e.g. 0.62.0-rc.5-staging);
4. Do a react-native init/@react-native-community/cli init (pls halp);
5. Commit all the changes to staging branch and push it;
6. Create PR from staging branch (0.62.0-rc.5-staging) to tag branch (0.62.0-rc.5);
7. This PR needs to be reviewed, approved and merged by a maintainer;
8. After the PR is merged the diff is automatically shown on upgrade-helper and used in the CLI.

If any of the automatically-handled steps fail, create an issue on rn-diff-purge mentioning that the process failed and tag maintainers.

Pros

• We can double-check the diff before it hits upgrade-helper;
• Will run as soon as there's a new tag in react-native repository.

Discussion points

• How to handle the RELEASES file in this scenario? updating it will require two PRs, perhaps having another GitHub action to see that a PR was a merged then update the file automatically? 🤔

[pvinis]

First, awesome suggestion, Let's do it!

2. Create a branch (e.g. 0.62.0-rc.5) and push it (should be done on top of the last release branch);

I wouldn't put it on top of anything. Currently, all new branches are started from the app-base branch and they are all independent, I think we should keep it like that, so we can generate diffs from any to any release.

Also, about the discussion point, one possible solution is we have the purge repo and we have a diffs repo. One PR in the diffs repo for RELEASES and diff files, and no PR but just a new branch in the purge repo for the init-ed app.

Another solution might be we keep just the one purge repo, and yea, we make two PRs. One is the changes in the RELEASES file that will eventually get merged, and the other is the diff files, which will never be merged. We would need to review the diff files PR, if we are ok with that, then we close that PR, and only merge the first PR. Then we keep the diff files PR just for accessing the diff files from the upg-helper.

Both solutions I'm ok with. One we keep one repo and we change the diffs "storage way", the other we separate the repo into two, and we change the scripts to handle the two repos.

[kelset]

we could probably also take a look at this https://github.com/acoates-ms/rnw-diff

From @ngerleman's message:

Just in case there is interest, we have a workflow to automatically run react-native-init and commit it to a branch in the style of the diff repo. You could probably just copy most of it wholesale and just remove the bits that run react-native-windows-init.

[pvinis]

Closing this. We have that and it's working.