#657 breaks workflow

[Mike-Hermans]

Since tag 5.12, which includes #657, release-drafter no longer correctly drafts our releases. We commit everything on master, but the actual build (and tagging) happens via GitHub Actions which pushes a new commit to master-build, which also gets the tag.

The build result is committed and tagged. When a new pr is merged, master will overwrite master-build with the new code, and the build process will start again. This means that the previous build step that was tagged now no longer exists in master-build.

The last tag on master is from over 6 months ago, and now release-drafter includes all pull requests from that point when drafting the new release. Is there an option to disable this feature, or work around it?

[RichardBeadle]

We appear to be hitting the same issue. We run release drafter on our develop branch so the team have visibility of whats coming along the pipe and so that we have a set of release notes before the code is released to master. Is there a way to revert or disable the changes from 657?

[jetersen]

I'll point v5 to previous release. Than revert it in v5.12.1 later tonight

[jetersen]

the v5 tag is now pointing at v5.11.0
rolled back GitHub App as well to v5.11.0 which is hosted on heroku.

Your GitHub Action workflow should look like this. The important part is uses

name: Release Drafter

on:
  push:
    # branches to consider in the event; optional, defaults to all
    branches:
      - master

jobs:
  update_release_draft:
    runs-on: ubuntu-latest
    steps:
      # Drafts your next Release notes as Pull Requests are merged into "master"
      - uses: release-drafter/release-drafter@v5
        with:
          # (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml
          # config-name: my-config.yml
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[RichardBeadle]

All working a-okay for me now - thanks @jetersen !

[jetersen]

reverted in #682