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 <javascript:>> > *To:* jenkins...@googlegroups.com <javascript:> > *Cc:* egru...@gmail.com <javascript:> > *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. > > > > > > > > >
