I don't understand how you can create a "controlled environment" which won't lose commits. The reason git disallows non fast-forward merges by default is described in the "git push" man page. It includes the following text with the --force option: "This can cause the remote repository to lose commits; use it with care."
Can you describe how you have structured that controlled environment so that it does not lose commits when you force a non-fast forward commit onto the remote repository? I don't think there is a way for the Jenkins Git Publisher to perform a merge as part of the post build action. It can push the results of a pre-build merge, but can't perform a post-build merge as far as I can tell. You either need that (which will then place commits in the working copy which have not been evaluated as part of the just completed continuous integration job), or you accept that you'll lose commits with "git push --force". Mark Waite >________________________________ > From: Juliano Picussa <juliano.picu...@gmail.com> >To: jenkinsci-users@googlegroups.com >Cc: Mark Waite <markwa...@yahoo.com> >Sent: Friday, September 28, 2012 8:06 AM >Subject: Re: Git plugin: push result of a merge > > >Hi Mark, thanks for the explanation. In my case the push -f will not because >it is a controlled environment. > > >However, I might I also use the git commands to resolve my problem. > > >However, I'm trying do this using jenkins git-puglin. In the post build > > >Merge Results (If pre-build merging is configured, push the result back to the >origin), but > >On Friday, 28 September 2012 12:29:49 UTC+1, Mark Waite wrote: >If you push with the -f or --force option, the entries on the master branch >which are on your central repository after the release_job will be lost. I >think you will be very frustrated that your Jenkins job pushed a change to the >master branch which lost your most recent work. >> >> >>We avoid that problem by having the most recent build of job_master tag the >>SHA1 which it built. After job_master has tagged the SHA1 which it built, a >>script in job_master performs a git fetch, a git merge, and a git push. The >>job_release is configured to always build from that tag which job_master >>updates, rather than building from the latest on the branch. If job_release >>needs to push changes back to the central repository, you could have it do >>something similar by tagging the SHA1 which it built, then perform a git >>fetch, a git merge, and a git push. >> >> >>That means those jobs are sometimes pushing something to the central >>repository which they have not built, but at least they can push to the >>central repository without losing recent work on the central repository. >> >> >> >>We have this condition because the team wants the version number checked into >>source control and incremented automatically on every build of job_master. I >>would have preferred to have a person increment the version number at key >>milestones, but the team preferred the automation of version number increment >>in the build because the version number is used widely in the system to >>version Microsoft.NET assemblies. >> >> >>Mark Waite >> >> >> >>>________________________________ >>> From: Juliano Picussa <juliano...@gmail.com> >>>To: jenkins...@googlegroups. com >>>Cc: egru...@gmail.com >>>Sent: Thursday, September 27, 2012 4:29 PM >>>Subject: Re: Git plugin: push result of a merge >>> >>> >>>I've got a similar issue: >>> >>> - I have 2 jenkins jobs for two distinct git branches: master and release >>>(1 job_master to 1 branch master / 1 job_release for branch release) >>> >>> - job_master has a post built configuration to push to the release >>>branch. >>> - job_release has a post built configuration to push to the master >>>branch. Before push, in the release_job the version file is increased and >>>committed to GIT. This is working fine. >>> >>> >>>The problem is when I run the release_job but the release branch is behind >>>of the master branch, the push to master does not work >>>(non-ff). Unfortunately, I didn't find the "push -f" in the jenkins post >>>built section. This way, or I have to push manually (using --force) or >>>configure a post built shell script (to push --force). >>> >>> >>>Have you found a way to use push -f or other solution for allow non-ff push, >>>using git plugin (publisher)? >>> >>> >>>Tks. >>> >>> >>> >>>On Tuesday, 14 February 2012 14:30:34 UTC, Emmanuel Grumbach wrote: >>>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 >>>>egru...@gmail.com >>>> >>>> >>>> >>>>On Tue, Feb 14, 2012 at 16:07, Mark Waite <mark...@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 <egru...@gmail.com> >>>>>>To: jenkins...@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 >>>>>>egru...@gmail.com >>>>>> >>>>>> >>>>>> >>>>>>On Sun, Feb 5, 2012 at 22:19, Mark Waite <mark...@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 <egru...@gmail.com> >>>>>>>>To: jenkins...@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 <sjt...@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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >>> > >
