Support skipping releases

Hey 👋

We implemented a feature to skip releases for our CDKTF pre-built provider bindings if neither the underlying Terraform provider version nor the CDKTF version had been changed. This is mainly driven by the fact that releasing on every dependency update that was merged to main causes us to run into limits in Registries such as PyPI.

However, our current approach uses some pretty ugly hacks and workarounds and I’d like to add proper support to Projen instead or at least properly expose options that enable us to set / override the required options.

We’re currently doing this (source):

    (this.tasks.tryFind("release")!.condition as unknown as any) =
      "node ./scripts/should-release.js";
    const releaseJobSteps: any[] = (
      this.github?.tryFindWorkflow("release") as any
    ).jobs.release.steps;
    const gitRemoteJob = releaseJobSteps.find((it) => it.id === "git_remote");
    assert(
      gitRemoteJob.run ===
        'echo ::set-output name=latest_commit::"$(git ls-remote origin -h ${{ github.ref }} | cut -f1)"',
      "git_remote step in release workflow did not match expected string, please check if the workaround still works!"
    );
    const previousCommand = gitRemoteJob.run;
    const cancelCommand =
      'echo ::set-output name=latest_commit::"release_cancelled"'; // this cancels the release via a non-matching SHA;
    gitRemoteJob.run = `node ./scripts/should-release.js && ${previousCommand} || ${cancelCommand}`;
    gitRemoteJob.name += " or cancel via faking a SHA if release was cancelled";

This basically consists of two parts:

1. Adding a condition to the release task to be able to skip building and bundling a release
2. Overriding the “check for new commits” Github workflow step in a way that it also aborts all further steps/jobs if a release was skipped

Part 2 was required because adding condition to the release did not cause the workflow (i.e. further workflow steps) to be cancelled because there seems no way for the workflow to know that it should be cancelled. This however, might be by design and I’m just misusing condition for something it was not designed to do.

Before I put up a PR, I’d need some guidance around the way you’d like to approach such a feature (I might be looking at this from a completely wrong angle). My current idea would be the following:

1. Add some kind of option for a skipRelease task/script/executable (that works like condition on tasks)
2. If that option is set, add a pre-build step to the release Github Workflow which runs this step and records its exit code
3. If that option is set, add an if config to all following workflow steps & jobs to skip them if the release should be skipped.

What do y’all think about this? Would you propose a different approach? Do you think skipping a release is a worthwhile feature at all?

[mrgrain]

My next step (after fixing the imports somehow) would be to catch this error in bump-version.task.ts and exit the process with a certain exit code which I could detect in the Github Action Workflow to have a way to differentiate an actual error from a “skip this release, but don’t fail it” – Or do you have a better idea to pass back that kind of data from the release task?

Hmm. I supposed we could introduce a new task bump:check that is run just before bump. Locally it would fail the bump (and release) tasks. In CI we would run bump:check in a special workflow job/step. It would be doin the check twice, but that doesn’t feel like a huge problem to me. Thoughts?

[mrgrain]

@ansgarm I’ve pushed a fix to your branch to disable esModuleInterop in the tsconfig.dev.json. Jsii doesn’t allow it so, we should be consistent here. It seems to pass your test now. 🎉