unmerged PRs listed on changelog

[valentijnscholten]

Hi,

I just noticed that my draft release has some unmerged PRs listed in the changelog

Releases: https://github.com/DefectDojo/django-DefectDojo/releases (referring to 1st draft release, 1.12.0)

Release drafter config: https://github.com/DefectDojo/django-DefectDojo/blob/dev/.github/release-drafter.yml
Release drafter workflow: https://github.com/DefectDojo/django-DefectDojo/blob/dev/.github/workflows/release-drafter.yml

The bottom 4 are PRs unmerged. What they have in common is that the PRs are wanting to merge a branch inside the same repo into the dev branch of that repo. As opposed to more common OSS PRs merging a branch in a fork into the upstream repo.
Not sure if that is the cause, but I added that test PR from a branch inside the same repo and it also ends up on the change log from release drafter.

Example: DefectDojo/django-DefectDojo#3686

Other PRs that are wanting to merge a branch from a fork are not listed. Which is correct because they are not merged yet.
Example: DefectDojo/django-DefectDojo#3684

When I look at the code, it is not doing any filtering on the merged_at field or merged/unmerged status of PRs. I am no js/graphql expert, but it looks like it is retrieving all commits in the repo since the last release. And all attached PRs. Regardless of being merged or not (or being on the dev branch/configured branch).

Is this a bug or somehow expected / desired behaviour?

Valentijn

[valentijnscholten]

I am testing a fix here: https://github.com/release-drafter/release-drafter/compare/master...valentijnscholten:fix-unmerged-prs?expand=1
But it's quickfix, probably could also be done by adjusting the graphql query.

[tylermassey]

I'm also seeing this issue

EDIT: For my case I fixed this by specifying the default branch with the commitish field in .github/release-drafter.yml. Our default branch is called "develop".

[Eun]

Had the same issue, I fixed it by disabling the github action for pull_request.

---

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:
          config-name: release-drafter.yml
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
                                                   

[dlucian]

disabling the github action for pull_request will probably turn off the autolabeler, so that's not a good idea for us.
specifying the commitish field fixed it without side effects.

[cmargonis]

I'm also seeing this issue

EDIT: For my case I fixed this by specifying the default branch with the commitish field in .github/release-drafter.yml. Our default branch is called "develop".

Hello! Tried to do the same but it doesn't seem to work. Do we also need to set filter-by-commitish to true?

[lukas-reineke]

Setting commitish does not fix the issue. The problem is that findReleases and findCommitsWithAssociatedPullRequests use the ref to find releases/commits.

release-drafter/index.js

Lines 153 to 157 in 349214e

	const { draftRelease, lastRelease } = await findReleases({
	ref,
	context,
	config,
	})

release-drafter/index.js

Lines 161 to 166 in 349214e

	} = await findCommitsWithAssociatedPullRequests({
	context,
	ref,
	lastRelease,
	config,
	})

But the ref might not be the branch you want to make the release against.

For example, if you have a master branch and a develop branch. And want to run release-drafter on PRs to develop, to use auto-labeler, it will create a release with PRs against develop. Because that is the current ref that findReleases and findCommitsWithAssociatedPullRequests use.
Running release-drafter only when the ref is master fixes the issue, but as mentioned above, this breaks auto-labeler

Either, don't run the release part of the action when auto-labeler runs, I think this would be fine, I don't see a reason to update a release on PR open. And it would be an easy fix.
Or, make findReleases and findCommitsWithAssociatedPullRequests use commitish instead of the current ref

[crazy-matt]

I guess that's what you want:

name: "Releaser"

on:
  pull_request:
    types: [closed]
    branches: [ "main" ]

jobs:
  update_release_draft:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: release-drafter/release-drafter@v5.15.0
        with:
          config-name: releaser_config.yml
          disable-autolabeler: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

That's nothing related to this action but the way Github works.

[lukas-reineke]

I guess that's what you want

Sure, turning auto-labeler off solves the issue, but I'd like to use it.

That's nothing related to this action but the way Github works.

Maybe I am misunderstanding something? If you have a PR from branch A to branch B, and releases are on branch C. Running release-drafter on that PR for auto-labeler, it will create a release with commits that are not on branch C.

[jetersen]

created #1015