RFC: Continuous Deployment Support

[EduardoAC]

Current behaviour

• We need to create a new branch and then attempt to merge that branch to trigger the publish

These have the following deficiencies:

• GitHub Actions doesn't trigger CI when the Octokit API creates the PR
• GitHub Actions workflow_run only applies to the branch where the version is triggered and not the PR generated.
• The fact that we need to cherry-pick when to yarn install without --immutable flag

Desire behaviour

Adding a flag called continousDeployment that allows to trigger on PR merge the following steps:

• Trigger version
• Create a commit on the main with the changes
• Trigger publish

I understand this has downsides and caveats. The idea behind it follows the same philosophy as the article Continuous deployments with Changesets + GitHub actions within the action itself rather than requiring additional setup.

Before starting work on a PoC, I would like to hear your thoughts and if it will bring value.

[jbrunton]

I found this issue because I was trying to figure out if I could configure the GitHub action to do just this. For me, the extra branching and PR steps are just additional hoops to jump through. I'd much rather have the new versions be automatically published by CI.

I understand why an OSS project might favour additional time to test and bake the main branch with a manual release mechanism, but for an internal team a continuous delivery paradigm often makes more sense.

[lachieh]

Just adding a bit of clarification here; you're always going to have issues with the first point, unless you create a token that isn't the default one from secrets.GITHUB_TOKEN. From GitHub's docs:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.

I've already got the flow you're talking about working with very few extra steps in the workflow but I definitely think there's room for the action to do more of this type of common work. I've previously used release-please for this type of automation, and their action was incredibly simple to set up. I think partially that's because most of the config is through their own file, but changesets also has a config, so it might not be too high of a bar to set in comparison.