How to configure this with gitflow?

[release-drafter]

How to configure this with gitflow?

[sullimander]

We would need the ability to set the release branch separate from the github default branch in order for us to use it.

[StewartSnow]

Hey we have the same issue here - we follow gitflow and would prefer that all draft releases are created on the master branch, rather than default develop branch (as is common under gitflow).
An additional config entry to indicate the branch that the release / tag should be drafted on would be most helpful.

Just to elaborate on the issue:

• We follow GitFlow, and as such the default branch is develop (not master)
• All feature / fix branches get merged into develop first
• Develop then gets merged into master for release
• We have "branches: master" which correctly ensures that release-drafter updates or creates the release notes on the merge into master...
• However, the draft release it creates is still on develop (despite the master branch being indicated in the config)

[jetersen]

Change your default branch to master?

Or perhaps we should provide a way to override the default branch.

[thibmaek]

That would mean all the PRs point at master by default and checking out the repo across team members starts from master. Kind of defeats the purposes of gitflow I think

[TimonVS]

Can you walk me through the issue you're having in a little more detail? I can see that you used the branches option in your config, why doesn't that give the desired result?

[thibmaek]

This is indeed the same problem I am encountering

[rvanlaak]

In our gitflow-like scenario we have master setup as develop, and production as master. What we see happening, is that release drafter nicely creates drafts for master`.

A problem we have (that sounds similar to the issue description) happens in the following scenario:

1 - A release branch gets created, testing starts and could take several days
2 - PRs that in the meanwhile get merged in master (read: the gitflow develop) and do not make the release - as they are not in the release branch.
3 - The release branch gets merged in production (read: the gitflow master) and gets tagged.

The actual problem that happened in the meanwhile: the PRs that get merged in step 2 do not appear in the next release draft.

[mkurz]

I think the problems you are facing can be solved with the filter-by-commitish config, I came up with this comment on how to change the target_commitish of a GitHub release: #656 (comment)

[mkurz]

You also might be interested in #1061