Replicate continuous release in non-GitHub actions Environment

[automartin5000]

I'm working on trying to replicate the continuous release workflow with the manual release workflow in a non-GitHub actions environment. I've been successfully using manual releases for some time to create pre-release builds and publish directly to npm, etc. from my local machine. However, I'd now like to replicate that in our CI environment on main merges.

I took a look at the projen release workflow, and it seems like release runs after push to main. I believe that means that projen release is expecting to be able to tag main directly. Is that correct? If so, I have a couple questions/concerns about this approach.

1. How does that work in an environment with protected main branches?
2. Wouldn't it make more sense for the tag to be applied when the PR is open on the head of the branch? You would then continuously move the tag on each commit. That way, when you merge, you have a pre-tagged branch, a pre-built dist, and all you need to do is publish. The only thing you'd have to make sure of is that the branch protection is on to ensure "branch is up to date with main".

Thoughts?

[mrgrain]

1. How does that work in an environment with protected main branches?

You'll need permissions to add a tag to the main branch. This isn't really a huge problem in my experience, but there are multiple ways of solving it. https://github.com/projen/projen has a protected main branch with "Do not allow bypassing the above settings" enabled. Tags are created via GitHub Releases, which uses unrelated permissions.

2. Wouldn't it make more sense for the tag to be applied when the PR is open on the head of the branch? You would then continuously move the tag on each commit. That way, when you merge, you have a pre-tagged branch, a pre-built dist, and all you need to do is publish. The only thing you'd have to make sure of is that the branch protection is on to ensure "branch is up to date with main".

I think the only way to make this happen is by ensuring that:

• PR is squashed, rebased and up-to-date with main
• Allow only fast forward merges to main so that after the merge the commits are exactly the same, i.e. HEAD(pr) == HEAD(main)
• PRs are merged in the order they are released, i.e. PR A with the release 1.2.3. MUST be released and fast-forward merged before we can look at PR B targeting release 1.2.4.

This all seems awfully complicated to me. So typically a system like this is instead implemented by having a develop and a release branch. AWS CDK does it like that. That's also a great pattern, just not one that's currently supported out-of-the-box by projen. Shouldn't be hard to implement though. But if you decide going down this path, I'd strongly recommend you forgo the existing Release component and start from scratch. It will be much easier than trying to "fix" a thing that is not designed for what you want to achieve.

[automartin5000]

So typically a system like this is instead implemented by having a develop and a release branch. AWS CDK does it like that.

Interesting, so is that something like gitflow then? I looked over at the AWS CDK CONTRIBUTING guide, but didn't see any documentation on it.

[mrgrain]

Yes aws-cdk repo does pretty much gitflow.

projen (by default) is more similar to trunk based development, with the exception that due to nature of open source projects, feature branches sometimes have to live a lot longer. However that part goes away in non oss projects.

[automartin5000]

Ok. So maybe what I want is to somehow combine bump and package without actually tagging the branch and waiting to tag the branch until merge?

[automartin5000]

And then run unbump? 😅

[automartin5000]

I realized I think that question probably doesn't make any sense out of context of the overall flow. I think I have what I need. Thanks!