Mark this repository as unmaintained

[andymckay]

Sadly we haven't got the time to maintain this repository as an official GitHub Action. In the last year or two since we originally published this, a large number of really good community Actions have appeared on the Marketplace for doing this.

We'd like to mark this repository as unmaintained and make it clear to users what their expectations should be.

People are of course free to fork this repository and maintain those forks if they like.

To do this we'll:

• Remove it from the Marketplace
• Remove from any official GitHub documentation.
• Change the README.md to clearly reflect its new state.
• Update the README.md to point to other community Actions.
• Archive this repository, putting it read-only mode. It will continue to work for all existing Action users, but won't receive any updates.

[leycec]

In the last year or two since we originally published this, a large number of really good community Actions have appeared on the Marketplace for doing this.

...and these vaguely unspecified but perfectly comparable alternatives that promise unadulterated bliss and a happy ending are what, exactly? 🤨

There probably should be similar GitHub Actions somewhere, but I can't actually find any. Were you just assuming fait accompli that viable alternatives existed when you wrote that – or did you actually find a few and assumed we could too? That'd be fair enough, except... I can't.

@saxbophone suffers a similar problem in the preceding issue:

It's a shame nothing else could be found on the marketplace, I think this repo is becoming unmaintained soon

Admittedly, I have all the Googling skills of an untrained rhesus monkey on a five-day banana bender – which is to say, I have none.

EDIT: Actually, I found two! Okay, basically just one. Without further ado, here are the closest approximations to this repository that I could grep up from the unwashed capitalist bowels of the GitHub Marketplace.

Github Release On Push Action

As the name implies, Github Release On Push Action, creates one new release and corresponding tag for each commit pushed to the main branch – which is fundamentally insane except for mostly legacy projects that still use git-flow.

The front matter is also largely unreadable. I mean, it's technically misspelled English, but just try parsing this at home without a stiff drink: "CI & CD systems are simpler when they work with immutable monotonic identifers from the get-go. Trigger your release activites by subscribing to new tags pushed from this Action."

I have no idea what an "immutable monotonic identifer" is, suggesting I have none. I didn't even know one could subscribe to tags dynamically synthesized by third-party Actions and trigger "release activites" (whatever those might be) from said subscription. In short, nothing makes sense.

Tag and Release

Tag and Release, follows the exact same methodology. In fact, they even explicitly reference (and deride) this Action in their front matter under the mistaken assumption that their opinionated workflow is magically better:

This action is meant to be invoked in response to a branch push to create a tag and a corresponding release, under the assumption that you can derive the tag name automatically. In contrast, actions/create-release is generally run on a tag push, expects the tag to already exist and only creates the release.

Wow! Well, where do I sign up? </shaking_my_head>

Again, this seems to assume git-flow. This also seems to assume that creating and pushing tags from local dev machines to GitHub-hosted repositories is somehow non-trivial and therefore worth automating.

Of course, these are all bad assumptions. Creating and pushing tags is trivial. No one needs help doing that. Everyone just wants GitHub to automate the creation of releases from existing tags like under every other repository host.

Release Action

Release Action, the most ambiguously and/or ambitiously named release Action in GitHub history, seems vaguely relevant. It creates new releases on new tags. So far, so good. It has 104 GitHub Stars. This is good, too. It's most recent commit was 12 days ago. Now we're cooking with hot lava!

But I remain unclear how to transition from this Action to that Action. That Action seems to explicitly require something to generate release tarballs:

name: Releases

on: 
  push:
    tags:
    - '*'

jobs:

  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ncipollo/release-action@v1
      with:
        artifacts: "release.tar.gz,foo/*.txt"
        bodyFile: "body.md"
        token: ${{ secrets.GITHUB_TOKEN }}

Note the unversioned release.tar.gz filename explicitly listed under artifacts:. That disconcerts me. I never had to manually pregenerate release tarballs with another Action and then notify this Action of those tarballs; all that just happened automatically without my manual intervention, which was nice, because I am lazy.

Ignoring that, the following release-action configuration seems to approximate our current create-release workflow at @beartype:

name: release

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    name: "Create tagged release on GitHub"
    runs-on: ubuntu-latest

    steps:
      - name: "Checking out repository..."
        uses: 'actions/checkout@v2'
      - name: "Publishing GitHub release from tag..."
        uses: 'actions/release-action@v1'
        with:
          name: "beartype ${{ github.ref }}"
          body: ${{ github.event.commits[0].message }}
          token: ${{ secrets.GITHUB_TOKEN }}

Untested, of course. No Markdown support for body formatting, of course. No automated tarball generation, of course. Still, that at least generates an empty plaintext-formatted release with body content culled from the current tag. It's something, anyway. And Odin knows we need something.

I expect convulsive blowouts on enabling that. I'm holding off until I get sufficiently desperate, which shouldn't be long now.

release-with-changelog

Ah, release-with-changelog. This Action's like the {insert childhood love interest here} that got away: you continually imagine what could have been with a pang of rose-tinted nostalgia, while ultimately firm in the conviction that you dodged a bullet there.

Superficially, release-with-changelog seems special – well, aside from that name. That's just an awful name. Like Release Action, it's actively maintained, creates new releases on new tags, and doesn't seem to pregenerate release tarballs. Unlike Release Action:

• It's much less configurable, which is bad.
• Supports Markdown templates, which is good.

Frankly, I'd rather have configurability. We can manually do Markdown templating ourselves, but we can't do configurability ourselves. Release Action gets the polite nod here.

This Is the End, My Active GitHub Friend

We'll probably end up opting for Release Action, but it's nice to know that something else exists. Aside from those two, however, the GitHub Marketplace is a vast swath of nothingburger – and finding even those two took the better part of Sunday evening, which I now want back.

So it goes. 😭

[ash0x0]

@leycec Found a couple more: marvinpinto/action-automatic-releases and softprops/action-gh-release. I ended up using the latter, was very quick and took care of all the cases like release in a matrix and existing releases and all the possible frills with creating and uploading.