search

voxpupuli / modulesync

Synchronize common files across your Git repositories.
Apache License 2.0
104 stars 48 forks source link

Are `bump` and `changelog` features relevant? #216

Open neomilium opened 3 years ago

neomilium commented 3 years ago

@ekohl and I started a discussion in #215 about this topic, so I quote my thought here:

From my point of view, whole PuppetModule class should be deleted from msync: most of us uses a local (ie. contained in each puppet module) rake task to bump its version, and for changelog more and more uses an algorithm to generate, it using github_changelog_generator...

Who use this feature these days? Do we need to keep puppet module's specific code in msync?

ekohl commented 3 years ago

Perhaps it would be better to have that functionality implemented via hooks. There is also other code I would like to execute (such as puppet-lint, rubocop) that is probably too complicated for modulesync. Personally I think modulesync should be as light as possible and solve problems via extensibility. Like UNIX tools should behave.

neomilium commented 3 years ago

I agree. Just for the story, I started to work on an execute command for msync first (see #199)... Even this #199 PR code is working and used by us (ie. opus-codium), I found the patches were made on top of a spaghetti code. So I started #206 which is the epic target and is currently split and parts are merged one by one (Thanks to reviewers for the help).

After #206, I will rewrote exec and push features on top of the cleaned code and we will be able to use msync as a light tool that "only" handles massive git repos and allow to apply a template to all of them.

ekohl commented 3 years ago

After #206, I will rewrote exec and push features on top of the cleaned code and we will be able to use msync as a light tool that "only" handles massive git repos and allow to apply a template to all of them.

That is exactly how I see modulesync.