[JIRA] (JENKINS-14568) Improve commit messages from SCM Sync Configuration

[fcamb...@java.net (JIRA)]

Frédéric Camblor edited a comment on JENKINS-14568 Improve commit messages from SCM Sync Configuration You misunderstood the "several modification changes on several files = 1 commit" Once JENKINS-13613 will be implemented, the commit changeset will be made of files modified during the http request of form submission. When you configure a job, only file jobs/foo/config.xml is modified [1], then, only config.xml will be commited. Unless you're not able to modify several job config files in 1 http request, you won't have more than 1 config.xml file per commit. [1] I simplified the case here to be more clear. In fact, during the jobs form submission, every plugin which plugged themselves on "job-centric" extension point, will have their Saveable.save() method called. Generally, most of them are working into a chunk of the jobs/xxx/config.xml file. Thus, when Saveable.save() is called on 1 plugin, the config.xml is saved on filesystem with new plugin state (and I commit this config.xml state in pre-JENKINS-13613, which explains why we have several commits on same file during a job configuration form submission). Sometimes, the plugins are not working into config.xml file, but in their own xml file. This is the reason why I say we could have multiple files commited during a HTTP request (if some plugin involved are not persisting their data into config.xml file). Note that I always spoke about jobs, but in scm-sync-configuration I never manipulate "jobs" but "saveables" that are a more generic class (a User is a Saveable for instance). That's why we cannot make the jobs workflow a general workflow case. The general workflow case is : Someone submit a form on jenkins Lots of Saveable.save() are called. They modify 1..* files on filesystem. I track these modifications. Once http request is done, scm sync config commit every changed files But everything occurs during 1 http request. When Saveable.save() is not called during a http request (on batches for instance), I won't be able (for the moment) to identify clearly the changesets. Thus, in that particular cases, I'll have to fallback into "pre" JENKINS-13613 behaviour : 1 commit per Saveable.save() In your particular case, wouldn't JENKINS-13613 simplify your life so much that you won't need file path in commit message anymore ?

This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira