How to ignore certain files from the "version bump auto-release" process

[marcelstoer]

This kind of builds on top of #76. However, since it's likely a missing feature I report it separately.

Scenario

• multi-module project with 20+ modules
• in the root folder I keep a few "management" files alongside the root pom.xml like .editorconfig, .gitignore and .gitlab-ci.yml.

Problem: a single change to any of those files will trigger the release of each module upon next invocation of the plugin as the root project changed.

I argue that this is undesirable in most cases. (How) can this behavior be turned off?

[marcelstoer]

@danielflower I would be happy to resource the development of this feature myself but I'll likely need some guidance from you.

[danielflower]

Yeah, this is a reasonable feature to have. How about something like a config option called <ignoredFiles> or something?

<ignoredFiles>
    <ignoredFile>README.md</ignoredFile>
    <ignoredFile>docs/whatever.txt</ignoredFile>
</ignoredFiles>

Could be expanded to be regex or in .gitignore format later.

[marcelstoer]

Yes, that's the easy part 😉Could you also give me a few hints where to integrate the checking against this configuration in the code. Which pieces need changing?

[Marx2]

this is also a problem with GIT submodules used, as GIT parent project stores hash of commit of each subproject. Commit in subproject have to be followed by commit in parent project.

[marcelstoer]

@danielflower I started looking into this and the current hypothesis is that I can work with path filters inside TreeWalkingDiffDetector. If you think this is a daft idea then please tell me quickly.

[talend-jphautin]

Hello,
I would appreciate this feature to be added as in most project We have a Jenkinsfile in the root of our repository that is not related to the project itself but to the CI of the project. This is also true when you generate a changelog on the parent project.

[marcelstoer]

@talend-jphautin #94 does address this.

[Romain125]

That is a feature that I've been waiting for a few years now.
I've seen the PR #94 but as it is built on top of #90 @danielflower did not accept it yet.
So...where do we go from here?
@marcelstoer would it be possible to create a new PR on a fresh master?
Or @danielflower, do you plan to integrate the #94 ?

Thanks to both of you for your work btw !

[marcelstoer]

@Romain125 Sorry, we gave up waiting and moved on.

[kobynet]

It shouldn't be too complicated to take @marcelstoer changes into a new branch from master if of-course @marcelstoer agrees to take parts of the code as-is.