Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marcelstoer opened this issue Jul 4, 2019 · 12 comments · May be fixed by #94 or #142
Open

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

marcelstoer opened this issue Jul 4, 2019 · 12 comments · May be fixed by #94 or #142

Comments

@marcelstoer
Copy link
Contributor

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
Copy link
Contributor Author

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

@danielflower
Copy link
Owner

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
Copy link
Contributor Author

marcelstoer commented Aug 10, 2019

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
Copy link

Marx2 commented Aug 12, 2019

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
Copy link
Contributor Author

@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.

marcelstoer added a commit to marcelstoer/multi-module-maven-release-plugin that referenced this issue Sep 24, 2019
This includes refactoring those methods that accept a ton of mojo
configuration parameters. There is now a single class that wraps all of
those.

Fixes danielflower#77
marcelstoer added a commit to marcelstoer/multi-module-maven-release-plugin that referenced this issue Sep 24, 2019
This includes refactoring those methods that accept a ton of mojo
configuration parameters. There is now a single class that wraps all of
those.

Fixes danielflower#77
marcelstoer added a commit to marcelstoer/multi-module-maven-release-plugin that referenced this issue Sep 24, 2019
This includes refactoring those methods that accept a ton of mojo
configuration parameters. There is now a single class that wraps all of
those.

Fixes danielflower#77
@talend-jphautin
Copy link

talend-jphautin commented Aug 10, 2020

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
Copy link
Contributor Author

@talend-jphautin #94 does address this.

@Romain125
Copy link

Romain125 commented Feb 23, 2023

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
Copy link
Contributor Author

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

@kobynet
Copy link
Contributor

kobynet commented Feb 26, 2023

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.

@marcelstoer
Copy link
Contributor Author

@kobynet Feel free to do whatever you want with my code.

@Cavva79
Copy link

Cavva79 commented Mar 19, 2024

Hi @danielflower,
if someone recreate pull request #94 from master, would you merge it?

Cavva79 pushed a commit to Cavva79/multi-module-maven-release-plugin that referenced this issue Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants