Question: Is it possible to filter labels/commits by path?

[pintomau]

Hi!

I have a project with a similar structure to https://github.com/pintomau/gib-mvp. In this project we have modules A and B that depend on different set of common modules, C and D.

When I'm releasing A or B, I want the change logs to contain only the affected modules. For example, if I'm releasing A, I want the changelogs to only include A and C commits for the change delta between 86aeea211cfe953641243c617ef771bc1f753e51...fd40f67d6918eaace986c1edb0e669d35d156a2d

I already know how to get the affected modules, which I can provide to the action, say "a" and "common/c". How can I configure the action to search for changes for these paths only, though?

In https://github.com/mikepenz/release-changelog-builder-action#advanced-workflow-specification I see we can define a single base path. But I think in this case I'd need a set of paths.

Thanks for the great work you put in here!

[mikepenz]

The path you reference to is very likely not what you are looking for, as that is mostly related to the git location within the CI (assuming that all of the modules are the same git project, this wouldn't be applicable) (https://github.com/mikepenz/release-changelog-builder-action/blob/develop/action.yml#L13)

---

There are possibly a few paths you can choose when building those changelogs.

Assuming you use PRs:

A possibly more simple approach (if you have labels which identify the modules) you could use ignore_labels to ignore PRs with given labels

Alternative you could only match categories exhaustive requiring a specific module label to be present alongside the specific category.

If your PRs don't have labels fitting these yet, an alternative would be to use the rules which allow more flexible identification and categorisation of PRs

An example from the test cases which uses a rule to categorize merged PRs with a title matching: https://github.com/mikepenz/release-changelog-builder-action/blob/5d1f9ae8899914f16a6b0891312bd22bff08258d/__tests__/transform.test.ts#L564-L574

[pintomau]

Hey. Thanks for the response.

Maybe a mixed strategy works for us:

1. Defines commit scopes for each common module
2. Dynamically find which dependent modules were affected between deltas for A (using https://github.com/gitflow-incremental-builder/gitflow-incremental-builder)
3. Dynamically configure the action's labels with only the scopes for A and its dependencies through configurationJson

I'm trying to avoid having to set the labels statically for each module, as this is a sizeable project with dozens of modules and collaborators, and I can foresee forgetting to update their labels when adding or removing dependencies.

Anyway, thanks for the clarification! Will continue to explore and evaluate.

[mikepenz]

You are welcome.

With the focus on not aiming to have a label for each Pull request (still assuming you use PRs)

The second suggestion of using "rules" to categorize is most likely the more flexible approach, as it allows you to use information from PRs to categories. Which offers the following fields: https://github.com/mikepenz/release-changelog-builder-action/blob/develop/src/pr-collector/pullRequests.ts#L10-L27

What is the main defining factor for the different features? Actual physical location of files? or do PRs have any identification for that too?

GitHub Actions offers a action which would be able to automatically add labels to PRs based on file changes: https://github.com/actions/labeler

Given a higher complexity, one suggestion. You can run the action as a test via GitHub codespaces, and test and debug your config that way. (if you want to iterate different options):

• https://github.com/mikepenz/release-changelog-builder-action/tree/develop?tab=readme-ov-file#local-testing-

[pintomau]

What is the main defining factor for the different features? Actual physical location of files? or do PRs have any identification for that too?

At the moment it's currently very loose definitions of conventional committing. Features usually only touch a single root module, but we may have a PR/commit that spans across the whole project.

Example: we're all using Spring Boot. If we want to upgrade Spring Boot for everyone, we may have an atomic commit, spanning across the project, to do just that.

However, each root module is releasable independently.

The second suggestion of using "rules" to categorize is most likely the more flexible approach, as it allows you to use information from PRs to categories. Which offers the following fields: develop/src/pr-collector/pullRequests.ts#L10-L27

GitHub Actions offers a action which would be able to automatically add labels to PRs based on file changes: actions/labeler

Did not know about this! Seems like a great candidate and would could resolve the issue with multi-module commits nicely.

[pintomau]

So, I ended up following your advice on using actions/labeler for this, and using labels instead of conventional commits.

This is what I ended up with as a fast sketch:

https://github.com/pintomau/gib-mvp/blob/42c0b448bc4a6243fbf8af6f9fa986588c357838/.github/workflows/release.yaml https://github.com/pintomau/gib-mvp/blob/42c0b448bc4a6243fbf8af6f9fa986588c357838/.github/labeler.yml

The "magic" part of the commons comes in https://github.com/pintomau/gib-mvp/blob/42c0b448bc4a6243fbf8af6f9fa986588c357838/.github/workflows/release.yaml#L85-L114, where with gitflow-incremental-builder/gitflow-incremental-builder I can check the affected commons, and input those to your action's configs dynamically.

[pintomau]

I resorted to a hack in https://github.com/pintomau/gib-mvp/blob/42c0b448bc4a6243fbf8af6f9fa986588c357838/.github/workflows/release.yaml#L111 to ensure unrelated commits would not appear there, as it seems like the behavior of having a category with an empty labels list is to include unrelated commits there.

Not sure if this is intended behavior.

[mikepenz]

Great solution @pintomau

On the last part. If you have a category which has no labels then it will pick anything uncategorised up. So that's expected and a feature.

Offering the ability to people who want a special section for PRs which got no labels or no matching labels to show up still.