Thanks for the explanation... I could use the git commands to fix my problem, using the "Post Steps" -> "Execute Shell" jenkins options. However, I'm trying solve my issue using the jenkins "Post Build Actions", where it is possible to add the "Git Publisher" and then choose the "branch to push/target remote name". Additionally, in the "Git Pusblisher" there is an option "Merge Results" (If pre-build merging is configured, push the result back to the origin) that is checked in my job_release. This way, I was expecting in the job_release post build, a merge of the release branch to my origin/master branch and then a push to the master. However, unfortunately, I can't see the merge...
So, my job_release changes only the version file (increasing the version), just it. But, as I said, the push to the master is not allowed if the release branch is behind of the master branch... 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. > > > > > > > > >
