Subversion 1.8 and Jenkins


  • I survived the hour long Uno hand

    Cartman's Ember.js woes felt so damn familiar, I figured I'd start a thread about my attempt to get Jenkins running.

    After months of talking and debating and planning, we're finally pulling the trigger: Jenkins will be involved in automatically testing and deploying code to our demo servers. (Not prod. We're not there yet.) We use Subversion for VC, and our current deploys are via Subversion: we move the code into a/the demo branch (depends on the application whether we have one demo branch or a fresh one every release) and then svn update/switch (depending on strategy) the demo box. Sometimes we restart coldfusion, but we're ignoring that for now, it's rarely necessary.

    Problem number one: We're using 1.8 working copies on the demo boxes. The Subversion plugin for Jenkins doesn't support 1.8, even though it came out A YEAR AND A HALF AGO.

    The next version will! When that comes out. Someday. But there's a pre-release snapshot! I install that. Somehow, Subversion claims I never sent credentials, even though I've changed literally nothing about the credentials stored in Jenkins that have been working with the old version of the plugin. I combed their wiki and JIRA (why the fuck are all Jenkins plugins tracked in the same JIRA with no ability to filter based on plugin when searching?! This should be simple: Search for "credentials", filter by "plugin-subversion". Nope. One or the other.) and found no reason this should have changed. I tried making a new credentials entry with the same credentials: no dice. I tried saving the credentials for the Jenkins user in svn command-line in case it can fall back to those credentials. Still nada.

    So I downgrade away from the snapshot and look through their releases list. Well, there's a stable beta version. I installed that, but it doesn't have the 1.8 compatibility.

    Final solution: Jenkins keeps a local working copy in 1.7 and uses a "shell script" task to run command-line svn to do the actual updates and deploys. Just like every other fucking task I have Jenkins doing: it's all shell scripts at this point. The only plugins I'm using are the ones that read in JUnit and Checkstyle formatted reports and make them pretty. Everything else is either "execute shell" or "conditionally execute shell".



  • [blakey]That's what you get for using that open source Belgium.[/blakey]



  • IIRC Jenkins (which was originally a fork of Hudson) has a new fork out that's newer because Jenkins was not being updated quickly enough. I don't recall what the fork is named though.



  • @mott555 said:

    IIRC Jenkins (which was originally a fork of Hudson) has a new fork out that's newer because Jenkins was not being updated quickly enough. I don't recall what the fork is named though.

    Please say Mr Belvedere please say Mr Belvedere...



  • I checked Alfred and Jarvis, but it looks like it's not those.



  • It was Travis-CI but I was wrong, it doesn't look like Jenkins/Hudson.


  • I survived the hour long Uno hand

    I've used Travis, it's nice, but IIRC only does open-source



  • @cconroy said:

    Please say Mr Belvedere please say Mr Belvedere...

    I'm still hoping for "Leeeeeeeeroy".



  • I should show Blakey the horrors of ClearCase or QualityCenter sometime -- he'll be wishing for the open-source tools (Bugzilla, SVN, etal) after exposure to that sort of belgium.


  • I survived the hour long Uno hand

    @tarunik said:

    ClearCase

    Jesus, now I'm having flashbacks. Fuck that noise.


  • Discourse touched me in a no-no place

    Hmm, I've not hit problems with SVN and Jenkins (though that might be because we've been migrating all our stuff to git, as part of reducing the amount of crazy in our repositories) but I've seen some horrible race conditions with the Jenkins Articfactory plugin. I'm not sure exactly, but it seems that if you've got a lot of dependencies, you can end up with the dependencies being downloaded just fine, but at least one of them never being registered as actually being present (cue failed build). It smells a lot like a race (or other threading bug) but I really don't want to investigate further: not using the artifactory plugin to acquire maven dependencies (but just letting maven do its usual stuff to pull from the artifactory server) is slower, but works reliably.

    Going the other way, just remember to do mvn install and not mvn package. Save yourself a few weeks of puzzlement. :blush:



  • In many projects, Jenkins ended up being a web UI for cron jobs, until I learnt to write plugins. Not very tough BTW, and pretty much is rewriting your script in Java or BeanShell or calling them from Java.


  • Discourse touched me in a no-no place

    @Yamikuronue said:

    fuck

    I think this is the first time I've seen @Yamikuronue swear, so that's how we know this is an annoyance to her.



  • We use Maven exclusively for building our flagship app.

    What's really going to be fun is when this project is switched from SVN / Hudson to TFS / TFS.


  • I survived the hour long Uno hand

    Really? Ha. I swear a lot in person.



  • At my work, we're using Jenkins for running unit and module tests. It gives us a horrendous amount of false positives - out of ten thousand UT and thousand MT, at least one fails in each build due to:

    • Filesystem problems
    • SVN server unavailable
    • Existing file is missing
    • Build slave times out
    • Jenkins getting uncaught exception
    • Messages not being received in time because test machines are too slow to handle load
    • Home-brew test framework crashing
    • Our app crashing for no reason (core dumps show segfaults in semaphores)
    • Everything is okay

    I'm sure at least some of it is caused by Jenkins and not by shitloads of makefiles and bash scripts and Python scripts and de-facto-homebrew language scripts and shitty codebase of our project. Because Java.

    Also, we have so many bugs we maintain multiple separate tracking systems for them, including multiple Redmine instances, multiple JIRA instances, one homebrew app, and emails.


  • I survived the hour long Uno hand

    @Gaska said:

    unit and module tests

    @Gaska said:

    Filesystem problems

    @Gaska said:

    Home-brew test framework crashing

    Ur doing it wrong.



  • @Gaska said:

    SVN server unavailable

    This is our main problem with Jenkins, our SVN server is extremely flaky.



  • @Yamikuronue said:

    Ur doing it wrong

    And the test system is just the tip of the iceberg.


  • I survived the hour long Uno hand

    Your biggest problem with Jenkins is SVN.

    Okay then.



  • ...I guess I should be lucky that my SVN server is hosted on the same machine as Hudson/Jenkins? (We've switched back and forth between Hudson and Jenkins because of issues.)


  • I survived the hour long Uno hand

    I don't think I've ever seen our SVN server go down or crap out or whatever. Maybe I'm lucky :)



  • @Yamikuronue said:

    I don't think I've ever seen our SVN server go down or crap out or whatever. Maybe I'm lucky :)

    True, but there can be network issues between servers.



  • We found that Jenkins couldn't deploy code across a one-way trust network boundary so we switched to Thoughtworks Go. There was a bit of a learning curve but so far it works beautifully.


  • I survived the hour long Uno hand

    I'm beginning to suspect putting this system in place without official blessing was the best of all possible ways I could do this. I've got a server inside the same network domain as the other servers and the SVN server, no trust boundaries or anything. The only time I've ever seen SVN shit itself is when I did something stupid to it and ended up with tree conflicts. I have no idea what ya'll are doing with SVN that'd cause network issues not to be resolved at the protocol layer just fine.


  • I survived the hour long Uno hand

    Taking 20+ minutes to do an svn switch because of the network, now, THAT I can relate to....



  • Worst thing you can do with SVN is git-svn. Do one merge under Git and all your SVN-using coworkers cannot do anything more complicated than commit file change.


  • :belt_onion:

    Ehr, git-svn just barks at you if you try to push a git merge, or did someone discover a "force" switch?

    Last time I checked, git-svn cannot store git merge commits and Subversion and hence won't even try to.



  • I'm mostly certain ours is flaky hardware or misconfigured networking. Lots of things on that particular box are flaky.



  • @JBert said:

    Ehr, git-svn just barks at you if you try to push a git merge, or did someone discover a "force" switch?

    It does? Never heard of it. I just do "git merge branch; git commit -a; git dcommit" and it Just Works™ - no warning, no confirmation, no nothing. And it works like that for all the people in my project.

    I wish it did warn, though.



  • My team uses CircleCI and it seems pretty stable (we use git though).


  • :belt_onion:

    Sorry for the confusion, it looks like the documentation now says you can dcommit git merges with the subtext that you shouldn't.

    Either I must have encountered an error before by doing something weird or by using an older version where the Git magic was spotty.

    At any rate, try to keep programmers who are new to git away from git-svn, it is such wizardry that you might take longer to understand what git does underneath.


  • Discourse touched me in a no-no place

    @JBert said:

    At any rate, try to keep programmers who are new to git away from git-svn, it is such wizardry that you might take longer to understand what git does underneath.

    I used it, but only one way: migrating from SVN to Git. (Our SVN repo was a mess; our Git repos are… much better, but we'll probably have to do some sort of migration again.) It required a lot of thought and testing and trial and error, but it did manage to get the job done eventually and didn't make too big a mess of the history (the mess it made, we managed to tidy up and was all caused by the awful state things were in).

    I had the advantage of being able to stop people from committing changes while things were ported (luckily everyone was busy with other stuff at the time) and to switch immediately to the new system after the migration. We still have the SVN repo, but it's now read-only (because of possibly third-party URLs into it).


  • :belt_onion:

    @dkf said:

    @JBert said:
    At any rate, try to keep programmers who are new to git away from git-svn, it is such wizardry that you might take longer to understand what git does underneath.

    I used it, but only one way: migrating from SVN to Git.

    Ok, but that's a bit of a corner case, and you've dealt with it in a very sane way.

    I'm talking in the "using it regularly"-sense, in which case I've seen a few people wedging their repo in a "rebase failed" state and trying all kinds of git powertools like reset --hard or checkout -f to undo whatever git svn rebase did. All that because they don't understand yet that they might be changing local history or what git svn actually does under the hood.


  • Discourse touched me in a no-no place

    @JBert said:

    Ok, but that's a bit of a corner case, and you've dealt with it in a very sane way.

    Well, I did have a key advantage: I knew I never wanted the changes to flow to SVN. That meant that I could give it a SVN URL that didn't have credentials to write.

    It took quite a few attempts before I was able to reliably get the git clones I wanted. Any time things went wrong, I scrapped the working repo and started again. (git clone --mirror FTW!)



  • @JBert said:

    At any rate, try to keep programmers who are new to git away from git-svn, it is such wizardry that you might take longer to understand what git does underneath.

    The problem is, they used Git for years and refuse to do their job with SVN anymore.


  • :belt_onion:

    Wait, and those are the same ones who can't be bothered to work properly for their SVN compatriots when they should perfectly know how to do so by now (i.e. not rebase the crap out of your branches and supply mergeinfo when it's a SVN branch)?

    I don't know what's the bigger WTF: sticking with SVN or letting people clobber the repo. I wonder how SubGit would deal with this, though most likely it would also put some constraints in place.

    You have my sympathy though.



  • I think they secretly hope that by sabotaging mergeinfo, the company will officially move to git.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.