We're using Gerrit. We thought we could do the following:
create some commits on a topic branch:
- a
- b
- c
Push those commits to gerrit.
Get some reviews.
Have Jenkins build only the last commit of the bunch.
Unfortunately, it looks like gerrit internally creates three different branches for those three commits, and when we have Jenkins run the script to build the topic, it winds up picking a different commit than the one we intended. Is there someway to get the behavior we desire?
You can change the project configuration to only create one review for your series of changes. This can be done by setting the Create a new change for every commit not in the target branch to false
Biggest disadvantage is that you can't review what has been changed in the changesets leading up to the latest change.
See the Gerrit Documentation
Gerrit always creates one change (review) for each commit pushed. There's no way to create one unique change for a bunch of commits. Commits are stored in special branches (like, for example, refs/changes/12/40312/1) until they aren't submitted (merged in the final branch).
You can, of course, build several commits at once after they are submitted to the branch but you only can trigger Jenkins to start a build every time some commit is merged in the branch (one build for each commit). If you want to have just one build for a bunch of commits you could consider to make scheduled builds started automatically some time of the day (night builds).
Related
In my company we have the following workflow: development is done on a dev branch, once author wants to merge the changes he/she squashes the changes and create a Pull Request. If during the review turns out the rework is needed then the author adds new commits to the branch. Once everything is approved the author should squash commits and rebase the code (if needed). Then the maintainer merges the branch to the master branch, which results in one commit only to be added (plus the merge commit). This is to keep the log neat.
However occasionally the maintainer overlooks the fact the commits on the dev branch weren't squashed which results in multiple "work in progress" commits to be included in the master branch. We want to avoid the situation. The question is how to do that?
I was looking through Pull Request "merge check" plugins that could e.g. disable "Merge" button if there is more than 1 commit between source and destination branches, but so far I haven't found any.
I know we could enable automatic squashing on merge but we decided not to squash automatically. We feel it's better for us if the squash is done manually by the developer, e.g. commit message may be corrected accordingly.
Correcting the history in the master branch is also not possible due to our policy forbidding rewriting history on that branch.
After completing a series of local commits into a local branch of a project using git and Gerrit, I push that series of changes into Gerrit for review and ultimately merge. In Gerrit, I see the "Submit With Parents" button for all but one of these commits. This is expected behavior, and I have come to understand why.
In Jenkins, I also utilize a Jenkinsfile to build out my pipelines and in doing so I also use the Gerrit Triggers plugin to react to the event stream in Gerrit. More specifically, I hook onto the merge event to trigger release ready builds for testing purposes.
When I submit each change individually, Jenkins triggers a build and moves along it's merry way building things one at a time. But... If I merge with parents (assume large feature implementation), Gerrit triggers an event for every single commit in the series. What I am curious to know, is if there is a way in either Jenkins or Gerrit to only handle the event from the child commit and omit the events for the parents?
Jenkins/Gerrit have not a way to handle specifically this but I'll suggest some workarounds:
1) You could add a "Topic" to the Gerrit Trigger on Jenkins with something like a "build" value. Doing this, Jenkins will only build merged changes of this topic and you only need to add the "build" topic to the child change to let Jenkins know what commit you want to build.
2) You could change the Gerrit trigger from "Change Merged" to "Comment Added Contains Regular Expression" with something like a "build" value. Doing this, Jenkins will not build when the changes are merged and you can trigger the build from the child commit just adding a "build" comment in the child change on Gerrit.
I hope this helps
I'm setting up a new Jenkins job using multibranch pipeline and I have noticed that when a branch is deleted, it only has a strikethrough and isn't actually removed on Jenkins. This is solved by re-running branch indexing. However, I cannot really use this as it will also cause every other branch to rebuild (a consequence of how the repository is updated). Is there some custom code or pipeline/script I can run to re-index without building?
I've already looked at various UI methods such as suppressing SCM triggers, but this also negates push events from Github which is something we want to use.
The deleted/merged branch build will disappear after a period of time (<24 hours). It is not removed immediately to show the recently deleted/merged branches and give a chance to review the prior build statuses. It is relatively harmless since the jobs for these branches are deactivated (read-only).
Note that the removal is based on the branch indexing job running at regular interval, so if you have this disabled, it probably won't do it (not sure the SCM webhook calls are enough).
I Have been working on bitbucket and jenkins for android applications. I am having many branches in my repository and i want to track just my master branch in jenkins where it meets the following criteria. 1) When we push any code with name 'A' into master it should automatically trigger a build.2) when we push a code as name 'B' into the same master branch it shouldn't trigger the build. Is there a way to do it. I tried excluding branch by using :^(?!.release).*$ but it is picking all other branches too.
Can anyone help?
You can specify which branch to be built in your job like this:
If you don't want the build to occur for specific codes then you can add them in to the Excluded Regions
Go to Additional Behaviors under Git in your job configuration and select Polling ignores commits in certain pathsand add the paths to the files for those you want to ignore builds if any changes happen to them:
This should work!
Is it possible to do pull request in bitbucket style in Phabricator?
Eg. to branch off of some existing branch and then to create pull (merge) request to merge new branch back?
I see that Phabricator differential tool only allows to submit some manually entered diff to some branch. Is it the only way?
You can mix git and arc together, but it does go against how arc diff is meant to be used.
You could leverage audit instead, although I haven't gone into any details about that below (nor have I used audit, yet).
Below, I've tried to explain our new workflow, coming from git-flow to an adapted version using git and arc diff.
Background
Before we started using Phabricator we used Gitlab and created merge requests. These would get reviewed by another developer. We use JIRA and our workflow incorporates a review required stage which has several checks before progressing into testing.
At this point, we've pushed the branch to the remote, requested a review and awaiting testing to occur (we have a mix of both manual and automated testing).
Once the review has been accepted and tests have passed, the feature branch is merged into origin/develop.
New workflow
Our new workflow removes the need to create the merge request within Gitlab, especially for reviewing.
My team still uses a workflow that incorporates git-flow, however, we've introduced the arc diff command. This creates the diff within Phabricator. The developer pushes his branch to the remote, but doesn't raise a merge request.
We run the following commands when creating a diff (merge into origin/develop)
git checkout -b feature/foo
git add <files>
git commit -m "A useful commit message"
git push origin feature/foo
arc diff origin/develop # this creates the diff within diffusion
Once the review has been accepted, we don't merge (or arc land) the branch, we await all testing to take place. This allows us to update the diff should testing fail and the developer who reviews can easily see which commits need reviewing.
Once testing has passed we can simply merge, either using gitlab merge request or the command line. We usually run arc close-revision <revision-id> to close the revision within Phabricator itself.
Additional notes
I believe the philosophy of arc diff is that you don't push your local branch. Instead you create a diff which diffusion displays. This is classed as a pre-push workflow.
Phabricator also has a post-push workflow which incorporates audit. You can simply mark commits ready for audit by amending your commit messages.
No, see https://secure.phabricator.com/T5000 to track this feature request.
Differential's primary input should be Arcanist, the Phabricator command line tool. It wraps git and provides lint, unit, and other precommit checks that help reduce time spent reviewing code. For example, it can emit patches and amend code before submission for review.
https://secure.phabricator.com/book/phabricator/article/arcanist/