|
Hello,
I have two git repositories: X-auto and X-dev, both have a master branch. The X-auto one is built automatically from upstream (and can be broken from time to time). The X-dev is the one people actually use for their daily work. From time to time, I merge from X-auto to X-dev and run a few test before pushing the merge to X-dev/master.
My goal is to have Jenkins do that for me. I would like to do the following: 1) build X-auto if that succeeds, then 2) merge X-auto to X-dev and push to auto_merge_jenkins branch. Then I can trigger an automatic test suite that can take the code from X-dev/auto_merge_jenkins.
All this works (almost). I configured the Git publisher to push HEAD (which will include the result of the merge) to X-dev/auto_merge_jenkins. The first build worked, but the second failed since the it was a non-fast-forward push.
So, is it possible to make the git publisher use git push -f instead of regular git push ? Or at least to add this as an option ? Currently, I push manually in the build step.
Thanks ! |
|
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 2012/2/2 Emmanuel Grumbach <[hidden email]>: > Hello, > > I have two git repositories: X-auto and X-dev, both have a master branch. > The X-auto one is built automatically from upstream (and can be broken from > time to time). The X-dev is the one people actually use for their daily > work. From time to time, I merge from X-auto to X-dev and run a few test > before pushing the merge to X-dev/master. > > My goal is to have Jenkins do that for me. I would like to do the following: > > 1) build X-auto > if that succeeds, then > 2) merge X-auto to X-dev and push to auto_merge_jenkins branch. Then I can > trigger an automatic test suite that can take the code from > X-dev/auto_merge_jenkins. > > All this works (almost). > I configured the Git publisher to push HEAD (which will include the result > of the merge) to X-dev/auto_merge_jenkins. The first build worked, but the > second failed since the it was a non-fast-forward push. > > So, is it possible to make the git publisher use git push -f instead of > regular git push ? > Or at least to add this as an option ? > > Currently, I push manually in the build step. > > Thanks ! > > Emmanuel Grumbach > [hidden email] |
|
Hi,
On Sun, Feb 5, 2012 at 00:32, Sami Tikka <[hidden email]> 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. |
|
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
|
|
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 [hidden email] On Sun, Feb 5, 2012 at 22:19, Mark Waite <[hidden email]> 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
|
|
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 [hidden email] On Tue, Feb 14, 2012 at 16:07, Mark Waite <[hidden email]> wrote:
|
|
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:
|
|
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
|
|
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:
|
|
In reply to this post by Mark Waite
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:
|
|
In reply to this post by Juliano Picussa
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
|
|
You are right. Git push --force is dangerous and lose commits...
I was testing the Merge Results options ("Post-build Actions" -> "Git Publisher" -> "Merge Results"). If pre-build merging is configured ("Source Code Management" -> "Merge options"), the "Merge Results" push the result back to the origin. It means that, "Merge Results" option in fact performs a push git command, and not a merge. What I was looking for (without "Execute Shell") is to configure a simple post build merge (between release and master branches), and then a push (from release to master). However, I think there is no this option (post build merge and push) in the Jenkins job configuration. If you find something else, please let me know. Tks, Juliano On Friday, 28 September 2012 15:56:17 UTC+1, Mark Waite wrote:
|
| Powered by Nabble | Edit this page |
