1.19.0 broke our prerelease builds

[sandyscoffable]

Describe the bug

In PRs we use prerelease builds. We get Github to automatically update versions in the files and commit these before triggering a prerelease (because lets face it, incrementing release numbers is irritating and prereleases could be derived from branchnames etc etc).

Since 1.19.0, the creation of releases stopped working.

To Reproduce

Create a Github action that uses this plugin to create a prerelease, but immediately prior to calling the plugin adds a commit to the branch.

Call the plugin with the following parameters:

        token: ...
        tag: 1.19.0-mysuperspecialtag.1
        commit: my-super-special-branch-name
        prerelease: true

Expected behavior

A prerelease to be created in Github, as per behaviour 1.18.0

Actual behaviour

Action succeeds, no release is created

Additional context

The input parameters unroll to the following with defaults (this was copied and pasted from the output, I redacted tag + commit):

Run ncipollo/release-action@v1
  with:
    token: ***
    tag: 1.108.0-something.1
    commit: branchName
    prerelease: true
    generateReleaseNotes: false
    immutableCreate: true
    makeLatest: legacy
    omitBody: false
    omitBodyDuringUpdate: false
    omitDraftDuringUpdate: false
    omitName: false
    omitNameDuringUpdate: false
    omitPrereleaseDuringUpdate: false
    removeArtifacts: false
    replacesArtifacts: true
    skipIfReleaseExists: false
    updateOnlyUnreleased: false

[sandyscoffable]

I should add that setting immutableCreate: false fixed the issue, however this wasn't a major version bump and therefore I'd expect new versions to be backwards compatible 🙏

Thanks again, it's a useful plugin 🙇

[ncipollo]

Did it create a draft release?

[ncipollo]

It was not intended to be a breaking change 😅. Not quite sure how this broke your workflow, but I've pushed a new patch version which defaults this property to false.

[ncipollo]

I tested a similar scenario using commit and tag with immutableCreate on and it seemed to work fine - https://github.com/ncipollo/actions-playground/blob/branch/testing/.github/workflows/tag.yml#L41.

I'm not publishing a commit as part of the workflow but I can't imagine why that would impact it. Do you have any other workflows in the repo having an issue? For example, something that kicks off when a draft release is pushed?

The way immutableCrate works is it first creates a draft, then publishes artifacts to it, then it publishes it.

[sandyscoffable]

Ok, this is weird. I can see the releases in GitHub now, where I could have sworn they weren't there before.

We've got other actions that are triggered by the creation of a release which were no longer triggered (it's how I initially noticed the problem). And switching immutableCreate to false meant those jobs started being triggered again.

Downstream release trigger (note: nothing filtering out draft builds etc):

on:
  release:
    types: [created]

However it might have been due to GitHub issue/outage (it was the first thing I checked and everything was green), or just general Github behaviour.

The exact sequence of events for our repo:

1. Developer pushes a commit prefixed with [prerelease] in the message
2. A custom Github action figures out what the version of that should be (depending on where the branch is merged up to, and how many prereleases are in the current branch etc etc .. tldr: get a useful unique version)
3. The custom Github action writes the version into the various package.json / pom.xml / build.gradle / etc files, and commits it
4. The custom Github action triggers the release-action against the end of the branch, which now contains this extra commit
5. New prerelease created is created by the release-action
6. Further domain specific things are triggered due to the creation of the release (deploying builds etc)

So it seems that for whatever reason, 6 wasn't happening. And I could have sworn 5 wasn't happening either, even though these releases now exist.

It's worth noting that the downstream things were never triggered. i.e even though the releases may / may not have been there, these things weren't triggered, and mysteriously setting immutableCreate to false seemed to fix it.

[ncipollo]

K - closing this for now. You can leverage immutableCreate to disable this behavior if you aren't actually using immutable releases. This default to false for now in 1.0, but I will likely push a 2.0 in the near future where this defaults to true (so I'd keep in explicitly configured if you plan to update).

[mara004]

@ncipollo I think it'd be great if immutableCreate: true would always fail intentionally when immutable releases are not enabled in the repository, as that could be used to safely trace an immutable release to a workflow. See bblanchon/pdfium-binaries#206 (comment) for background.

However, you could still use tristate (I mean something like immutableCreate: null) for a default that supports both modes.