Oh I do have this setup. But the tests I want to run per-commit are much lighter that when I merge from the community. My goal is to have Jenkins push --force to a branch (since it can't be ff as I explained), and trigger a huge regression that I can't control and that fetches the code from the branch.
But in any case I am happy with what I have now. I just thought it could be a "nice to have" Emmanuel Grumbach egrumb...@gmail.com On Tue, Feb 14, 2012 at 16:07, Mark Waite <markwa...@yahoo.com> wrote: > I think (based on other conversations on the mailing list) that the Gerrit > plugin may provide the type of workflow you're describing. I haven't yet > installed and configured Gerrit, so I can't answer from experience, but I > believe others on the list have stated in the past that a "pre-tested > commit" workflow is available through the combination of Git and Gerrit and > Jenkins. > > Alex Blewitt published an article in InfoQ > http://www.infoq.com/articles/Gerrit-jenkins-hudson which gives an > introduction. I believe I've also watched a screencast from Alex on the > same topic. > > Mark Waite > > *From:* Emmanuel Grumbach <egrumb...@gmail.com> > *To:* jenkinsci-users@googlegroups.com > *Sent:* Monday, February 13, 2012 11:35 PM > > *Subject:* Re: Git plugin: push result of a merge > > First sorry for the late reply, somehow your mail didn't pop up anywhere > so I just saw it... now. > > I guess I need to explain a little the purposes of the branches and it > will be clearer: > My project is in sync with the community so that I need to merge code from > outside quite often. The thing is that I would like to test it before I > introduce to the main branch so that people don't get mad because "yet > again someone broke something in the community". So it goes like this: > > I have 2 trees A and B. A is the main tree people actually work on. B is a > mirror of the community. > Jenkins merges from B to A and pushes to a branch "merge_from_community" > in A. That way I have the latest internal + merge from the community in a > separate branch. If tests pass on that code, I can push _manually_ to the > A's master branch. > Note that this branch is not fast forward: if someone pushes something to > A, "merge_from_community" has to be rebased. > > This is the flow. > Frankly, I don't really bother to push manually in my script, I just > thought that I might not be the only person interested in pushing --force. > Of course this has to be configurable. > > Emmanuel Grumbach > egrumb...@gmail.com > > > On Sun, Feb 5, 2012 at 22:19, Mark Waite <markwa...@yahoo.com> wrote: > > I think adding the force option to the git plugin would be a mistake. We > lost submissions when a user used "--force" with their push. I realize the > submissions were still somewhere in the object store, but they became > unreferenced and much more difficult to locate. Ultimately it was easier > to recreate the history (and forbid non-fast forward submissions) than to > locate the unreferenced commits. > > Can't you make your submissions a fast forward by performing a merge from > the remote branch first? Or are you truly intending to remove repository > history from your Jenkins job? > > Mark Waite > > *From:* Emmanuel Grumbach <egrumb...@gmail.com> > *To:* jenkinsci-users@googlegroups.com > *Sent:* Sunday, February 5, 2012 12:55 PM > *Subject:* Re: Git plugin: push result of a merge > > Hi, > > On Sun, Feb 5, 2012 at 00:32, Sami Tikka <sjti...@gmail.com> wrote: > > This should work if you use the git plugin to do it. > > > > Configure your job with both X-auto and X-dev repos. > > > > Then open the git advanced configuration and check "Merge before build". > > > > In Post-build Actions check "Git publisher". > > > > I have a somewhat similar setup at work. > > > > -- Sami > > > > I did that, the issue is that the git publisher can't add the -f flag > to the push operation. My push is not fast forward. > > > > > >
