search

jenkinsci / last-changes-plugin

https://plugins.jenkins.io/last-changes
https://plugins.jenkins.io/last-changes/
31 stars 31 forks source link

Implementing last changes for multi git and git submodules #64

Open pratts opened 5 years ago

pratts commented 5 years ago

Hello,

Currently the plugin supports single git/svn repository. There is an issue regarding the support for multiple git repositories here #42

I would like to contribute towards making that feature in the plugin. I am thinking of doing it in some of the following ways:

  1. In each multi-git setup, provide the configuration parameters for each repository
  2. Provide a configuration file in the project, the revision parameters for each repository, OR
  3. Provide a configuration file with revision parameters in each repository in multi-git and submodules.

We use both multi-git and submodules in our jenkins configuration. I would like to contribute towards extending the functionality for them as well.

Any feedback will be appreciated.

rmpestano commented 5 years ago

Hi @pratts,

thanks for weighing in on this feature.

I have zero experience with multi git repos but I can help on any issues related to the plugin itself e.g evolve the API to support multiple repos.

How can I test/validate your ideas? can you provide a sample jenkins pipeline dsl? there is a public git repository we can use as example?

We will support svn?

We also need to discuss the UI changes.

@dnalain and @astifter you're still interested in this? Can you have on validating the ideas of @pratts?

astifter commented 5 years ago

@rmpestano Nope, sorry.

timblaktu commented 4 years ago

I request this feature as well, at least the submodules part. I would say there's not really any new configuration required, other than perhaps enabling/disabling recursive submodule changelogs.

Everything you need is there in your plugin. You already have the before and after commits which you're currently using to diff the main repo. The before and after commits for each submodule are stored in the main repo tree. From that you do a "git foreach" type walk for every submodule, and repeat the steps you're already doing for the main repo.

I can see that the presentation of this is a concern. From what I can see, your current diff2html presentation tree could just be extended, linearly, down the page like a list. So, instead of what you're doing today:

main repo diff header main repo tree . . .

you'd do this:

main repo diff header main repo tree . . . submoduleA repo diff header submoduleA repo tree . . submoduleB repo diff header submoduleB repo tree . .

I would say this would have high value for users even without implementing support for recursive submodules, i.e. just go one level deep and you'll make 90% of people happy.

FWIW, even the Git Plugin itself doesn't do this: https://issues.jenkins-ci.org/browse/JENKINS-6334 I point this out because there, the problem has been solved, and you can peruse their patch and methodology. The reason why it's not been released yet is just because they don't have much of a submodule test automation safety net and are (rightly so) risk averse.