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 [email protected]. For more options, visit https://groups.google.com/d/optout.
