Only include commits that contain modifications to a path prefix

[blast-hardcheese]

I'd like to have multiple configurations of release-drafter in order to maintain multiple distinct versions in the same repository.

release-drafter does permit configuring a tag prefix, as well as custom template locations, so the only missing component is the ability to choose which commits to include.

From the CLI, I'm looking at something like:

user$ git log --oneline -- module/foo/src/main  # This would be tracked in foo-v1.2.3
user$ git log --oneline -- module/bar/src/main  # This would be tracked in bar-v2.3.4

I'm happy to do the work here, just opening this issue to announce intent.

[blast-hardcheese]

I've got a proof of concept set up, I'll clean up the code and submit a PR after I've used it for a bit in my project

[jetersen]

newer version supports multiple _extends for configs levels

filter-by-commitish should help you

[blast-hardcheese]

@jetersen It seems as though filter-by-commitish would be used to maintain multiple individual branches, but I'm trying to release multiple multiple modules, colocated in master -- am I misunderstanding something here?

[jetersen]

So do you release all modules at once in the same release, ie what your looking for is grouping pull requests inside the draft according to path.

Or would you want each module to be in an individual release making separate release drafts?

[blast-hardcheese]

The latter -- Each module is binary compatible with the others, so if the modules are structured as a tree (core branching out to leaf modules with highly specific functionality), I should be able to bump the leaf modules without having to release all other modules.

It may be easiest to see how I've got things set up in my project:

• Releases
• .github/ containing configs
• config section I added to filter PRs containing paths

and, if necessary,

• my fork of release-drafter to add the functionality I was after

[jetersen]

@blast-hardcheese some of these changes looks fine. Perhaps if you could prepare smaller pull requests for the separate bits we can get them into this repo?

emptyVersionInfo is definitely a nice fix :)

includePaths should be optional inside the graphql query.

[jetersen]

You could use extends to reduce the amount of config repeat you had to do and only overwrite with versioning stuff than you don't need a regenerate-release-drafter.sh

ie.

name-template: 'scala-http4s-v$RESOLVED_VERSION'
tag-template: 'scala-http4s-v$RESOLVED_VERSION'
tag-prefix: scala-http4s-v
include-paths:
  - "modules/scala-http4s/src/main/"
  - "project/src/main/scala/Build.scala"
  - "project/src/main/scala/modules/scalaHttp4s.scala"
_extends: guardrail:.github/release_drafter.yml

[blast-hardcheese]

You could use extends

Oh, that's a great tip! I'll clean up some PRs, starting with emptyVersionInfo. Thanks for taking a look!

[mkurz]

@blast-hardcheese Would my suggestion in #1061 help you to fix your use case? Instead of path's you could maybe use filter-by-commitish and my concept of overriding target_commitish values to exclude releases from certain workflows. Not sure however if it really works for you, I thought I post my idea anyway.

[masashi-sutou]

The latter -- Each module is binary compatible with the others, so if the modules are structured as a tree (core branching out to leaf modules with highly specific functionality), I should be able to bump the leaf modules without having to release all other modules.

It may be easiest to see how I've got things set up in my project:

• Releases
• .github/ containing configs
• config section I added to filter PRs containing paths

and, if necessary,

• my fork of release-drafter to add the functionality I was after

@blast-hardcheese

• your changes sounds great. Do you have any plans to issue a PR in the near future?

[jetersen]

@masashi-sutou The license is open and you can always credit him with co-authored-by as I did in #1067 which was borrowed from @blast-hardcheese 's fork 😅

[blast-hardcheese]

• your changes sounds great. Do you have any plans to issue a PR in the near future?

I intend to, yes, though I've got conflicting priorities in real life currently, so I've not yet been able to get back to this. Is it blocking something?

[jetersen]

I intend to, yes, though I've got conflicting priorities in real life currently, so I've not yet been able to get back to this. Is it blocking something?

Real life always gets in the way of the virtual life, hope all is well ☺️

[blast-hardcheese]

I intend to, yes, though I've got conflicting priorities in real life currently, so I've not yet been able to get back to this. Is it blocking something?

Real life always gets in the way of the virtual life, hope all is well ☺️

Getting to know our daughter, all is well 😊

[jetersen]

Getting to know our daughter, all is well 😊

Well that is a excellent excuse to focus on real life 😅
Congrats 👏

[masashi-sutou]

@masashi-sutou The license is open and you can always credit him with co-authored-by as I did in #1067 which was borrowed from @blast-hardcheese 's fork 😅

@blast-hardcheese @jetersen

• Thank you for your reply. OK, I'll try PR.

[blast-hardcheese]

OK, following up on splitting up my feature branch, starting with includePaths, then support for prefixed tags.

[jetersen]

released in https://github.com/release-drafter/release-drafter/releases/tag/v5.19.0

[masashi-sutou]

@blast-hardcheese @jetersen

• Thank you for implementing the great features ☺️