I have a problem with getting Google's Repo, gerrit & Jenkins working together.
our setup:
we have a Repo build out of few git repositories, which are all on our gerrit server. Manifest is also there.
Workflow:
user do changes in few files which sits in different git repositories in the Rep.
user commit & push the changes to Code review.
Problem:
for each of the repositories, a separate gerrit code review is created.
For each of those code reviews, Jenkins is being triggered.
If the changes are inter-depended (which they usually do), the Jenkins build will fail, as it takes only the changes in one repository each time.
How do we make Jenkins/Gerrit co-op to get the full changes into one build (that will work)?
Thanks
The configuration described here is very problematic,
and is sure to cause you grief in the future as well.
In the long run, consider one of those paths:
Reduce dependency between the components to the minimum
(this is preferred)
Merge the code to a single repository
Meanwhile -
Make sure the verification-job (in Jenkins) checks-out the latest code from all the other repositories
(those that are relevant for building this change)
Make (non-breaking) changes to one repository at a time
(requires some planning, of course)
Related
I have previously use Jenkins and BitBucket on premises and been able to have Jenkins notify bitbucket of the build condition of each individual branch (success, failed, in progress) however since I moved to bitbucket cloud it has started applying the condition of every build on every branch to every branch. For example if I have just a master and develop branch (to keep it simple) and the master branch failed because of some deployment configuration I am unable to merge a fix into it from develop even if develop is passing because it claims 1 of my 2 builds is failing on the develop branch.
This is tough to explain clearly in words so I've attached some pictures:
Two branches one build failing but both being marked as failed
Showing that develop branch is passing
Proof it wont let me merge
These notifications come from jenkins and have been set up using the standard cloudbees-bitbucket-branch-source:2.9.7 plugin to scan my bit bucket cloud.
Okay so this was a really obvious mistake but I thought I would leave the reason why this happened here in case any one makes the same mistake. cloudbees-bitbucket-branch-source:2.9.7 notifies bitbucket using the commit ID, when creating the branch structure for the repository I branched off main to make develop and both got built but both had the same commit ID and so both were notified of both builds. The problem fixes it's self on the first cycle of code to run through it.
For our projects have Integration and Master branch. For deployment we cut a RC branch off Integration. Once deploy is complete we create Pull request for RC to Master.
However, now Master shows as 1 ahead because it has a commit that does not exist in Integration. I considered to create Pull request RC to Integration as well, but TFS does not allow it since there are no changes.
Is there a way to avoid this situation with Master? Can behind/ahead only check the code changes and not commits? To fix this I now have to create Pull Master to Integration, and that is a pain for all the projects we do.
Afraid not able to avoid this situation. It's also not possible to make behind/ahead only check the code changes and not commits. Since you are using Pull Request (which execute git merge --no-ff).
To be honest, it's not necessary to resolve Integration branch behind/ahead master.
you can have two mostly independent branches without any problems. The important measure of differences between branches is given by git diff. If this reports no differences, then it's Ok.
You could also take a look at this similar question: VSTS Git: Is it necesary to resolve dev branch behind/ahead master and if so how?
If you insist on avoid the ahead on Master, you may have to create Pull Master to Integration as you have pointed out in the question.
I would like to have Github releases created automatically from the code of Jenkins-job. Ideally, I would like that these releases have also the generated release-notes in description that might be manually edited afterwards if necessary. Is it possible to write the Gradle-task or code (in Jenkinsfile) which make it work?
We use Gradle as a build tool. Already have Git plugin installed on the Jenkins server. I guess that the Github API should be used (https://developer.github.com/v3/repos/releases/#create-a-release ), but as far as I see a release can be attached only to ONE commit (with its tag), while I would like to see eventually ALL commits that come along with this release (and since the previous one), not only the latest commit.
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/
We just switched to using Hg Flow, but one of things that we still haven't quite yet figured out is how to best use Jenkins with it. Ideally we would have a job which builds and tests develop, one that builds and tests default and other jobs which are automatically created when a feature or release branch is created, and ideally also delete the job when the feature or release is finished.
Does anyone know if this can be done, and if so, how exactly to do it?
It would be extra nice if Jenkins was able to read from Hg who it was the created the branch and mark them as the contact person if/when the job builds, but this is really just a nice to have.
Thanks in advance
There is a Job Generator Plugin that could be used here. You'd create a job that watches the entire Hg repo for changes, and when it sees one, you run a task that parses the commit, and creates a new job with the new branch in place of templated fields.
If you can see a history of branch creation, you could use that information only in your job-creating task to fill out contact details too.
I haven't tried it myself, but I found this plugin (for GitFlow):
Jenkins Build Per Git Flow Branch
This script will allow you to keep your Jenkins jobs in sync with your
Git repository (following Git Flow branching model).
Also see the author's blog post on this plugin.