git checkin command doesn't work with renamed files

Code changed in jenkins
User: Frédéric Camblor
Path:
src/test/java/hudson/plugins/scm_sync_configuration/repository/HudsonExtensionsGitTest.java
http://jenkins-ci.org/commit/scm-sync-configuration-plugin/b4ea03118051348882ded4467fd79c3fb4724cbf
Log:
Ignoring shouldJobRenameBeCorrectlyImpactedOnSCM in HudsonExtensionsGitTest due to JENKINS-15128

SCM-694 improvement should be available in Maven SCM 1.8.1

Maven SCM 1.8.1 is shipped since November 1st

I don't understand. The MSCM1.8.1 is out there for almost one month, but the restriction isn't yet lifted. Or we wait for 1.9 (i don't know what “align” means in that case)?

If you're not happy about how fast things are done, don't hesitate to contribute... plugin is opensource.

Maven scm api is a dependency of scm-sync-config plugin.
The latest thing to do since 1.8.1 is released, is to align scm-sync-plugin on this version, test if no regression is implied, and release.

No, no problem at all with how fast the things are done! At least you do it. Other problems i've reported are being ignored altogether But well, «À cheval donné on ne regarde pas la denture» =

I just need to evaluate the time until it's fixed. For example, if it takes one year, i will revert back to our self-written system to store Jenkins config in SVN. If it takes one month, i'll tell people to stop renaming for a while.

I won't have time to work on scm-sync-config 'til mid-december.

But after, this issue (and more generally, every critical/blocking issues) is in my short list

It wouldn't be so bad if renaming of jobs would just not work with the Git backend. But what I'm seeing is that in case of renaming a job all files below jobs/<new_job_name> including all builds and the complete workspace get committed to the Git repository that is supposed to just hold the changes to configuration files. As a result, the Git repository size has grow to over 7 GiB for our project. Given this, I'd say this is a blocker.

If this is really the case, I completely agree with you...

Changed priority to blocker in order to spot this in my next release sprint backlog

I don't know how clear is the implication — as it's not stated explicitly — but deleting job doesn't work either.
The priority's a blocker already, so nowhere to augment…

Code changed in jenkins
User: Frédéric Camblor
Path:
pom.xml
src/main/resources/META-INF/plexus/components.xml
src/test/java/hudson/plugins/scm_sync_configuration/repository/HudsonExtensionsGitTest.java
http://jenkins-ci.org/commit/scm-sync-configuration-plugin/6281daf4184fddcaf74b073af56fc8de0f42b8a3
Log:
AL on maven-scm-provider-gitexe 1.8.1 (thus maven-scm-manager-plexus 1.8.1) => fixing JENKINS-15128 (handling job rename with git)

Code changed in jenkins
User: Frédéric Camblor
Path:
src/main/java/hudson/plugins/scm_sync_configuration/scms/customproviders/git/gitexe/ScmSyncGitExeScmProvider.java
src/main/resources/META-INF/plexus/components.xml
http://jenkins-ci.org/commit/scm-sync-configuration-plugin/f7660046a918b6cc456a6408fe0428efeedf9276
Log:
JENKINS-15128: Fix job rename with Git by providing a custom GitExeScmProvider allowing to explicitely set "origin" as remote branch during push (in order to update local reference to avoid problem during subsequent call)

Note this issue is not yet fixed, had to push my current local state due to https://github.com/jenkinsci/scm-sync-configuration-plugin/pull/14

Is there any progress on this issue? have been some months now since last progress update.

As I said in the PR 14, this is not this simple

The last time I looked at it, I was stuck on some svn/git differences in behaviour (having to rely on a generic layer for SCM manipulations is not always obvious).
This makes me wondering if current issue is "fixable" given the current state of the project.

It might be handled if I was dropping the use of scm API (that is to say, reimplement only my needed commands) and use jenkins' own credential api (see JENKINS-18129)

Would extending the upstream Jenkins SCM API to your needs then be an option? That at least sounds to be less work than using the credentials API yourself, and other plugin developers would benefit from your work, too.

In the scm-sync-config plugin, there are 2 SCM API used (and bridged) nowadays :

• Jenkins SCM API : used mainly for authentication
• Maven SCM API : used mainly to provide an abstraction over "standard" scm commands

Problem with SCM API are :

• I don't know them very well (don't think it is well documented either)
• I don't think it is as rich (in terms of abstractions) as the Maven SCM API (I don't think, for instance, that there is a generic method allowing to "commit" things on the repository ... since jenkins doesn't need to commit anything generally .. it only uses scm to checkout source files).

On the SCM API side, problem is not with lack of generic layered methods, but differences in behaviour in these ones.

For instance, update() with svn will do an `svn update` (thus, working copy will be up to date, and ready for subsequent modifications). A svn delete will then be taken into account directly.
Whereas update() with a git impl will only do a `git fetch` (working copy not up-to-date (only origin references are updated)), thus we will need either a 'rebase' or 'merge' to include changes to push them on the upstream remote. These methods don't exist because they are too DVCS-oriented (and couldn't be implemented in non-DVCS scms).

Moreover, changing things in SCM API takes time because adding a generic method needs every scm implementation to provide their impl for this new generic method

This is the reason why I think the better solution will be to implement our own generic impl for plugin needs only

Does anyone have an idea for a work around? I am still unable to check in new changes to git using the plugin.

Some things I have tried and failed:
*manually committing the changes from the checkoutConfiguration folder
*deleting the checkoutConfiguration folder
*deleting the scm-sync-configuration.fail.log
*changing the git repo location and putting it back
*manually adding the folder to git so that the plug in could allow the commit including the deletion of the folder
*the steps found here: JENKINS-19229 comment
*manually deleting the checkoutConfiguration/jobs/rcx-datamodel folder

This is the error I receive:

Jan 02, 2014 1:53:15 PM hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
SEVERE: [deleteHierarchy] Problem during remove : The git command failed.
Jan 02, 2014 1:53:15 PM hudson.plugins.scm_sync_configuration.SCMManipulator
FINE: Deleting SCM hierarchy [/var/lib/jenkins/scm-sync-configuration/checkoutConfiguration/jobs/rcx-datamodel] from SCM ...
Jan 02, 2014 1:53:15 PM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness
FINEST: Processing commit : Commit hudson.plugins.scm_sync_configuration.model.Commit@2f023ff1 : 
  Author : John Doe
  Comment : Job [rcx-domainmodel] hierarchy renamed from [jobs/rcx-datamodel] to [jobs/rcx-domainmodel] by John Doe
  Changeset : 
    A jobs/rcx-test-data-framework/config.xml
    A config.xml
    A jobs/rcx-domainmodel/
    D jobs/rcx-datamodel/ 

The problem appears to be with the rcx-datamodel job that is deleted. The Git master has already deleted the folder.

What is odd is that the rcx-datamodel job is already missing from the /var/lib/jenkins folder in Jenkins and is missing in the git repo.

Is there a good way to start the scm-sync-configuration over from scratch without deleting the git repo?

Hi,

Workaround for job renames is :

• Stop Jenkins
• Manually `git mv` directories in the checkoutConfiguration/ directory, commit change, then push the commit to your repository
• Restart Jenkins

In last resort, you can switch in the global config page : Git SCM => No SCM + save => Git SCM + save
This will result in :

• Resetting checkoutConfiguration/ content (changing scm resets the directory)
• Performing a new "initial sync" with the repository, that is to say :
  • Clone repo into checkoutConfiguration
  • Add folders located into your JENKINS_HOME/ and not present into checkoutConfiguration/ to the repo

Initial sync has a drawback : if you have checkoutConfiguration/foo and JENKINS_HOME/foo doesn't exist, foo won't be removed from your repository (I prefer not to remove such files due to "reload files from repo" feature)

Thanks Frédéric. I will try this shortly. I appreciate your help.

Eric,

Any updates on your success? We are running into a similar issue, where I am seeing the following:

1) Job has been deleted via standard process.

2) Directory and subdirectories appear under /var/lib/jenkins/jobs but no actual files in the directory structure (!?).

3) Directory and subdirectories are completely absent from var/lib/jenkins/scm-sync-configuration/checkoutConfiguration/jobs

4) Git repository shows that the job folder and all subfolders and files have been deleted from master by "SYSTEM".

5) Get errors during every sync run that says:

Jan 21, 2014 4:59:08 PM FINE hudson.plugins.scm_sync_configuration.SCMManipulator
Deleting SCM hierarchy [/var/lib/jenkins/scm-sync-configuration/checkoutConfiguration/jobs/SomeJob] from SCM ...
Jan 21, 2014 4:59:09 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.

Following both of Frederic's workaround suggestions do not result in any change in condition.

The only thing that is sticking out to me is that the two jobs that I've noticed this occurring on by name all have spaces and parenthesis in them (e.g. "Some Project (1.x)"). Not sure if that is relevant but perhaps worth note.

Any hope of seeing a fix for this? The plugin looked to be really useful when we first installed it, but this makes it unusable unfortunately (we have too many projects and developers to rely on manual fixes every time a project is deleted/renamed...)

Richard Raseley
This fix did not appear to work for me either. My job names have spaces in them but not parenthesis. I am still having problems. Unfortunately we are likely to remove this plug in and manage configurations a different way until this is fixed.

Another workaround is to avoid renaming jobs, and prefer create new job by copying the old one, then remove the old job.

Drawbacks for this solution :

• Build history is lost
• I totally agree this is not ideal, especially on large user codebase where we cannot keep an eye on everyone's job config

But this is the only I can provide now.
Fixing this issue would imply a big refactor on the way the plugin uses the scm abstractions (see my previous comments), and this is not something I have time to do nowadays.

This is the single biggest blocker for the usage of this plugin. I want people to freely rename jobs and give them better names as they see fit.

Code changed in jenkins
User: Frédéric Camblor
Path:
src/main/java/hudson/plugins/scm_sync_configuration/scms/customproviders/git/gitexe/ScmSyncGitExeScmProvider.java
src/main/resources/META-INF/plexus/components.xml
http://jenkins-ci.org/commit/scm-sync-configuration-plugin/dbf5431c5cbd19e4674567e9b437a744ac29fe3b
Log:
JENKINS-15128: Fix job rename with Git by providing a custom GitExeScmProvider allowing to explicitely set "origin" as remote branch during push (in order to update local reference to avoid problem during subsequent call)

Code changed in jenkins
User: Frédéric Camblor
Path:
src/main/java/hudson/plugins/scm_sync_configuration/SCMManipulator.java
src/main/java/hudson/plugins/scm_sync_configuration/ScmSyncConfigurationBusiness.java
http://jenkins-ci.org/commit/scm-sync-configuration-plugin/780cf5e7dffe3dd78a2037b99b6cfbde2b158dcf
Log:
JENKINS-15128: even if updatedFiles are empty, we should consider current commit as checked in in order to remove it from commitsQueue

Code changed in jenkins
User: fcamblor
Path:
src/test/java/hudson/plugins/scm_sync_configuration/repository/HudsonExtensionsGitTest.java
http://jenkins-ci.org/commit/scm-sync-configuration-plugin/b794c1a45f487e8579d8303ec1c0a31319fcb7d9
Log:
JENKINS-15128: Re-activated shouldJobRenameBeCorrectlyImpactedOnSCM

Compare: https://github.com/jenkinsci/scm-sync-configuration-plugin/compare/5fd7d4b3e6a8...b794c1a45f48

fixed in v0.0.8

I'm testing out the fix but still seeing an issue. It's throwing an error on:

[INFO] Executing: /bin/sh -c cd /var/lib/jenkins/scm-sync-configuration/checkoutConfiguration/jobs && git rm <old_project_name>
[INFO] Working directory: /var/lib/jenkins/scm-sync-configuration/checkoutConfiguration/jobs
Aug 26, 2014 7:03:49 AM hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
SEVERE: [deleteHierarchy] Problem during remove : The git command failed.

when I run the command manually, I get:

fatal: not removing 'jobs/<old_project_name>' recursively without -r

any thoughts?

mmm.. I didn't tested it against file hierarchy (to test, I only settled simple freestyle job, thus not having any subdirectories)

There must be another issue here, could you file another issue about this please ?

This actually doesn't have any subdirectories, it's just erroring because the target is a folder (the only thing inside is config.xml). Unless the job was a single file, I don't see how the simple rm would work.

Has a new ticket been opened for this as @fcamblor requested? We are encountering the same issue when renaming a job. The job folder has no subdirectories but contains a single config.xml file, hence a simple git rm <job-dir-name> fails.

I should add that we are using v 0.0.8 of the plug-in.

Seems not to be fixed. When renaming a job, we get this in the logs and all future SCM syncs fail. This is using the latest v0.0.8:

Apr 27, 2015 1:13:20 PM FINE hudson.plugins.scm_sync_configuration.SCMManipulator
Deleting SCM hierarchy [/root/jenkins/scm-sync-configuration/checkoutConfiguration/jobs/Frontend_Test] from SCM ...
Apr 27, 2015 1:13:20 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.

not fixed:
May 18, 2015 3:29:48 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.

What's the manual work-around for this issue? I haven't been able to figure out how to rectify this issue so that scm backups can proceed.

Do not rename a job; duplicate it, and remove the original.

A little late for that. =P The job has already been renamed.. but how do I fix the git part so SCM can proceed?

Restarting Jenkins has restart sync process successfully .

Fixed in 0.0.9

I see the following in checkoutConfiguration/

# git status
On branch master
Your branch is ahead of 'origin/master' by 10 commits.
  (use "git push" to publish your local commits)
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	renamed:    jobs/SQS Mertics/config.xml -> jobs/SQS Metrics/config.xml

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   config.xml

I don't know which config.xml failed to add.

I see the following repeating in the logs

Dec 17, 2015 1:37:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Dec 17, 2015 1:38:00 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.
Dec 17, 2015 1:38:01 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy
[deleteHierarchy] Problem during remove : The git command failed.

I manually fixed by:

ssh jenkins
sudo su jenkins -s /bin/bash
cd ~/scm-sync-configuration/checkoutConfiguration/
git status  # see untracked files
git add -a
git commit -a -m "manual commit due to failed rename"
git push origin master
# all good

Then restarting jenkins.

Please see my earlier comments; this is still not working for us.

Same as issue JENKINS-25786

Have exactly the same issue with 0.0.9

Looking forward to see https://github.com/jenkinsci/scm-sync-configuration-plugin/pull/32 merged, which appear to contain the fixes.

Added related to JENKINS-26652 link.

We are having exactly the same issue with 0.0.10 and are thus sadly forced to NOT use this plugin which would be awesome if this would work.
As soon as there is a job renamed/deleted, the plugin stops working at all and does not add any xml file to its folder which would be synced, thus a manual git commit/push does not help.
As previously said, https://github.com/jenkinsci/scm-sync-configuration-plugin/pull/32 seems to fix the issue. Please take a look at it.
Thanks and kind regards, Paul

I experience this issue intermittently on deletes, and this is the steps I do to resolve:

1. cd $JENKINS_HOME/scm-sync-configuration/checkoutConfiguration/
2. git status

Make sure the changes listed in git status make sense

3. If uncommitted files, git commit

4. git push

5. Clear the error message

6. Restart jenkins.  This is important, otherwise the error message will continue to pop up

Hi kylejw,

Your solution fix issue. I even create job that runs on master to fix it:

Jenkins Job Free type:

Restrict where this project can be run: master

Execute shell command: 

cd $JENKINS_HOME/scm-sync-configuration/checkoutConfiguration/

git status
git add .
git commit -m "Fix synchronisation" 
git push

The scm sync configuration plugin is deprecated. No further work is expected on the plugin.

Users of this plugin are encouraged to migrate their jobs to Pipeline Plugin, so that their jobs will be specified in pipeline code that can be checked into an SCM, all without using the SCM Sync configuration plugin.

Users of this plugin are also encouraged to use the Configuration as Code Plugin to specify the configuration of their Jenkins server in a file which can be checked into an SCM, all without using the SCM Sync configuration plugin.