Project

General

Profile

Bug #7029

Repair Jenkins' SCM sync

Added by intrigeri over 5 years ago. Updated about 4 years ago.

Status:
In Progress
Priority:
Low
Assignee:
Category:
Continuous Integration
Target version:
-
Start date:
04/05/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
No
Affected tool:

Description

The SCM sync plugin syncs configuration files to Git. Well, it did, until we upgraded Jenkins.

History

#1 Updated by intrigeri over 5 years ago

  • Description updated (diff)
  • Priority changed from Elevated to Normal

I've discussed this with bertagaz, and we agreed that it was actually no big deal: we don't configure Jenkins via the web interface anymore, so the only useful data (the initial config we did in the web interface, if any at all) is already in this repo. One should be able to replicate our setup by importing the outdated XML config from that repo, and then running jenkins-jobs update.

Downgrading priority accordingly.

#2 Updated by bertagaz over 4 years ago

  • Status changed from Confirmed to In Progress
  • QA Check set to Ready for QA

After a quick look, it was maybe due to the migration to Git 2.x and its change in push.default that needed to be set. I've configured accordingly the local repo. But that was a warning, so that might not be the reason the sync wasn't possible.

I've also asked Jenkins to flush the errors using a button on the web interface, and it is now claiming having successfully synced the conf today. I think that it was maybe in fact working, but keeping the errors on the webpages probably for the admin to see that somewhere in the past the syncing failed.

We'll see when we'll modify something in the Jenkins configuration, but this bug seems to have been resolved if it existed.

#3 Updated by intrigeri over 4 years ago

After a quick look, it was maybe due to the migration to Git 2.x and its change in push.default that needed to be set. I've configured accordingly the local repo. But that was a warning, so that might not be the reason the sync wasn't possible.

Good catch!

I've also asked Jenkins to flush the errors using a button on the web interface, and it is now claiming having successfully synced the conf today.

I've pulled the repo, and indeed I got lots of changes spanning from November, 2014 to June, 2015.

However, the most recent job update is from May 25, which feels strange. It would be good to try adding a job and checking in a couple of days if it indeed was pushed to Git.

I think that it was maybe in fact working, [...]

Well, each time I have pulled the config repo "recently", there was no change in there, so I have my doubts wrt. this hypothesis.

We'll see when we'll modify something in the Jenkins configuration, but this bug seems to have been resolved if it existed.

Yep. Great job! Not sure if it's fully fixed, but at least it seems that there are definitely some improvements already :)

#4 Updated by intrigeri over 4 years ago

  • QA Check deleted (Ready for QA)

The Git repo has nothing new since June 3rd, while our Jenkins config has changed since then => this is not really fixed.

#5 Updated by bertagaz over 4 years ago

Right...

I have no clue at the moment of what might happen, apart from a buggy plugin.

I created a specific logger in Jenkins as explained here

We'll see if something comes out of it when the configuration will change.

#6 Updated by bertagaz over 4 years ago

  • Priority changed from Normal to Low

So it has logs now, it seems things happen, but nothing is commited locally nor pushed to the remote still...

I suspect it might be that the plugin does not support recent git versions, it seems that it sometimes is really tightened to some version of the scm binary.

There also is an upstream ticket that looks close to what we meet, but without any proper explanation of the fix. Other unrelated bugs here

There is also a reference to a post about a bug in the job deletion

It is not much maintained to be honest, no update since almost a year (so compatibility with recent git > 2.0 is questionable), and depends on an old Jenkins version. There are also quite some references online of buggy behaviors. It's not so clear to me if/how we can solve this yet.

But his plugin is not so vital to us, so let it mark as low prio. I'll come back later on it.

#7 Updated by intrigeri about 4 years ago

  • Assignee changed from intrigeri to bertagaz

OK, thanks for looking into this.

But his plugin is not so vital to us, so let it mark as low prio. I'll come back later on it.

OK. Assigning to you accordingly, then.

If we ever have to modify important Jenkins settings via its web interface, then this will become higher priority, though.

#8 Updated by bertagaz about 4 years ago

  • Assignee changed from bertagaz to intrigeri
  • QA Check set to Ready for QA

I'm not so sure of what happened, but it seems to work correctly again.

I've restarted Jenkins, so that might be why, maybe it reloaded the git repo state from scratch, and then was happy with it. Sounds like something like that happened looking at the logs.

There are new commits now, so I think you can close this ticket.

#9 Updated by intrigeri about 4 years ago

  • Assignee changed from intrigeri to bertagaz
  • QA Check changed from Ready for QA to Dev Needed

I'm not so sure of what happened, but it seems to work correctly again.
[...]
There are new commits now, so I think you can close this ticket.

Last commits I see are from June 24, while there were Jenkins config changes today. Is there a lag, or what?

#10 Updated by bertagaz about 4 years ago

Hrm, that's right. It seems the plugin is happy after a Jenkins restart, because it succeeded to find the repo, but the bug reappears once we start modifying jobs. I can't get at the moment what kind of changes trigger it. The plugin logs I've created in the web interface give some infos, it does seem to at least try to commit things, but nothing happen.

Also available in: Atom PDF