So I ended up circumventing my problem by getting rid of the multi-configuration plug-in. I just pull once at the top, build everything in sequence, including both platforms, and commit at the end. Haven't had a problem since. Seems that the Hg plugin and multi-config just haven't been thoroughly tested together.
On Monday, April 21, 2014 4:24:33 PM UTC-4, bluntcoder wrote: > > Hi everyone, > > > I'm looking for some insight on the best way to set-up a > multi-configuration job in Jenkins using Mercurial. I have a project which > has two platforms: mobile and web. First off, Jenkins decides arbitrarily > which one to build first. Note that I have "Run each configuration > sequentially" otherwise everything really goes haywire. > > So whatever build it decides to build, (let's say mobile) - works > flawlessly. The end step of my build I have it committing to my repository > in the cloud and waiting a significant amount of time (30 seconds) before > the web build starts. When the second platform starts building, more often > than not - I get inconsistencies in my change logs, and frequent merge hell > and multiple branches happening. So my questions are: > > 1. Is any best practices when trying to avoid having Jenkins create > branches when committing fresh builds? Unfortunately I require the build to > be part of main branch, (I won't bother explaining why, it's complicated) > > Currently my setup works like so; > > - Standard clean update by mercurial via default branch > - > - hg purge > - hg update --clean (for paranoia) > - Build my project (which takes about 60-90 seconds) > - > - hg pull -u > - del *.orig /s > - hg addremove > - hg status > - hg commit -A -m "Successful build of %deployment% #%BUILD_NUMBER% on > %BUILD_ID%" > - hg push > - wait 30 seconds before finishing job > > That extra pull -u after the build is for merging any additional changes > that may have been submitted while the build was running. That's it. > > So when my second variable of my %deployment% axis starts, things go to > hell - especially if a previous build failed. The Jenkins change log > reports minimal changes (maybe 1 one changeset) while the third pull -u > then re-downloads what should have been downloaded from the previous build. > (Both platforms commit and push to the same branch). Often the platform > creates a new head - and I just can't make any sense of why this is > happening. > > Unless Jenkins always does a pull and an update right at the beginning > regardless of doing builds sequentially or not. That would definitely > contribute to this mess. > > Jenkins can't be this screwed up. It has to be me. I have to be doing > something fundamentally wrong by not understanding how multiple > configuration builds work - or at the very least, I don't know the secret > sauce which ensures my build repo will always be clean and ready to work > regardless the state of the previous build. > > Can anyone provide any insight? > > If I can't figure this out I'll resort to individual normal jobs and build > them with the parametrized trigger plug-in. > > Thanks! > bluntcoder > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
