I am creating jobs using Jenkins Organization Folders.
I want to continuously build against pull request.
However, when I create a pull request, it will be built automatically only the first time.
Even if I add commit to pull request, Jenkins does not build automatically.
I expect that build will work again when the commit is added to the branch that created the pull request.
I am using the following version of Jenkins / plugin.
Jenkins: 2.89.1
GitHub Branch Source Plugin: 2.3.1
GitHub Branch Source Plugin has the following settings.
Discover branches: Exclude branches that are also filed as PRs
Discover pull requests from origin: Merging the pull request with the current target branch revision
Discover pull requests from forks: Merging the pull request with the current target branch revision
Also, although I am using Github Enterprise, I think that the configuration of webhook is okay as the build runs instantly when creating the pull request for the first time.
There is two way to resolve this issue
1)
You have to configure your github repository so it inform jenkins of a new version: yourRepo/settings/hook&service/service ( the best practice)
or
2) you can configure your jenkins jobs so it check for diff time-to-time if the repo have been update :
yourJob/configure/Scan Repository Triggers/Periodically -> 10 min
In my project, we configure both, with a Periodically check of once a day
If you were talking about GitHub Organization folder, then
there is a section where you can configure automatic branch triggering.
Related
In a recent build of Jenkins (i.e., 2021-10-01 timeframe), how can I react to a GitHub pull request (PR) Close (or Merge) using declarative Jenkinsfiles and ONLY these "basic" Jenkins plugins?
GitHub plugin
GitHub branch source plugin
It seems that I should avoid GitHub Pull Request Builder since it can't react to PR close or merge.
Currently, everything works fine using a "GitHub organization" type project, when opening the PR and creating new commits on it (i.e., I see "continuous-integration/jenkins/pr-merge"), but when I click Close pull Request in GitHub, the Jenkins Build History doesn't react. I'm not sure why since, the "GitHub branch source plugin" states:
While the build triggers are often enough, you can set up webhooks to
automatically trigger builds when changes are pushed to your GitHub
repositories.
I am trying to setup TeamCity 10 for a larger project. We have 3 different GitHub repos which all are needed to build. They can't be build individually as the setup is today. If I set up the project with all of the GitHub repos I can put them all in one folder an successfully build everything.
The structures basically just looks like this:
Base repo
UI repo
Plugins repo
Which all checks out to the same folder and start building.
My problem now is that I need to run build on specific pull request per repo. I need a way to manually or automatically start a build for example PR 1234 on Plugins repo and then use the master on the rest of them.
I've tried several setups but I just can't get it to work as I want to. The best would be if the manual build start popup would have the "branch" drop-down menu for each of the repos but it always just have that one.
I thought about using snapshot dependencies but it seems like that would require each of them to be built individually which currently can't be done. I want them to be "pulled" individually and built as one project.
I appreciate any help on the issue and feel free to ask questions if something is unclear.
Thanks!
What I have done to achieve this is creating multiple VCS Configurations and 3 seperated projects.
Base Repo : Default branch : master
Base Repo : Default branch : master + Branch specifications +:/refs/pull/*/merge
UI Repo : Default branch : master
UI Repo : Default branch : master + branch specifications +:/refs/pull/*/merge
Plugin repo : Default branch : master
Plugin repo : Default branch : master + branch specification +:/refs/pull/*/merge
Base Repo Pull Requests:
We will build the Pull Request of the Base Repo (2)
This project will build the pull requests using UI Repo on master version. (3)
This project will build the pull requests using Plugin repo on master version. (5)
UI Repo Pull Requests:
We will build the pull requests of the UI Repo (4)
This project will build the pull requests using the base Repo on master version. (1)
This project will build the pull requests using plugin repo on master version. (5)
Plugin Pull Requests:
We will build the pull requests of the plugin repo (6)
This project will build the pull requests using the base repo on master version. (1)
This project will build the pull requests using the UI Tests on master version. (3)
EDIT:
How to handle the pull requests
From the comment, I complete this answer.
I created a watcher in order to launch automatically the build of the pull request. The watcher is a TeamCity Build which run peridoically with the schedule trigger feature.
Here is the pseudo code of the feature
parameters:
- ValidatorName
Load Octokit
// Filter is on every Open Pull Request
openPR = Octokit.PullRequest.GetAllForRepository(filter);
foreach(pr in openPR) {
// Define if the PR should be queued.
// Check if the PR is not already queued.
queuedBuilds = Execute-HttpGetCommand ("http://<teamcityServerUrl>/httpAuth/app/rest/buildQueue?locator=buildType:validatorName");
foreach(queued in queuedBuilds) {
if(queued.branchName = pr.Number) {
# Flag to not queue the build.
shouldQueue = false;
}
}
if(shouldQueue) {
Execute-HttpPostCommand(
"http://<teamcityServerUrl>/httpAuth/app/rest/buildQueue",
"<build branchName=""pr.Number""><buildType id=""validatorName""/><comment><text>Automatic launcher of Pull Request</text></comment></build>");
}
}
The notion of validator appear, and it is a special build, with snapshot dependencies of what we would like to test on our pull request.
This build will load octokit and use Octokit.MergePullRequest object.
If they can't be built individually then they shouldn't be in separate repos.
If they were all in the the same repo, it will save you alot of problems, and you can then control when to build via pull-request and feature branches.
I've added new GitHub Organization Folder Plugin item on Jenkins. It successfully added all repos with all branches, but no pull requests. I see special tab for each repo there with 'Branches' and 'Pull Requests': branches are properly collected while Pull Requests are empty no matter what I tried.
What should I do for to get them?
I'm using latest Jenkins LTS (2.19.3 + GitHub Organization Folder Plugin 1.5)
If your pull requests are based on branches in the origin repository (instead of a fork) they will be skipped.
If you want PR coming from origin branches to be processed, then you have to activate Build origin PRs (merged with base branch) in the additional settings section in the branch source configuration.
We are using a private GitHub Organization as version control. When a task is assigned to a developer, they fork the primary repository, make their code changes, and submit a pull request to have the changes merged into the master branch of the primary repository.
We are also using TeamCity for CI. It is currently configured to kick off a build for a VCS commit, which builds, tests, and deploys the artifact to an artifact repository internally. To accomplish this, the Team City build configuration has multiple VCS roots installed; one for the primary and 1 for each developer's fork.
The problem is that Team City pulls from all of them when a commit is made assuming they are all necessary for the build instead of allowing you to only pull from the single repository that triggered the build. Any thoughts on how we can accomplish this without having to create n build configurations in Team City for each project (where n == number of developers working on a project)?
I see way to do this with preserving current workflow is turning off automatic checkout (VCS Checkout Mode), and checking out code manually in an additional command-line build step, with a parameter %teamcity.build.branch% (logical branch name).
I.e.:
git clone ...
git checkout %teamcity.build.branch%
Triggers will just start the job if there are changes in developer's VCS root, fulfill branch env variable; no automatic checkout will happen and then build step will check out only needed branch. Only works with one git URL.
After posting in the JetBrains forums, I was pointed to a blog that answers my question.
TL;DR: my approach of using feature branches does not work with GitHub's workflow. Instead, Forks and Pull Requests should be used. The blog referenced shows how you can use Team City to trigger off of a Pull Request. Simply add +:refs/pull/*/head to "Branch Specification" in your VCS Root and all pull requests to the Source repository will trigger your Build Configuration.
I'm having an issue setting up Github and Jenkins CI.
When a forked PR commits changes, github doesn't notify jenkins, even if I've accepted the PR from a forked repo. Only when I merge a pr from a forked repo into master will github trigger Jenkins.
So the credentials and ability is there, but I can't find the option in github to force ALL commits to the original repo (including forked pr's) trigger the CI, anybody any suggestions?
The solution was to use the Github Pull Request Builder Plugin
There are instructions in the link above that worked for me. As well as the default instructions I had to also do this:
"This build is parameterized" and add string parameter named "sha1". When starting build give the "sha1" parameter commit id you want to build or refname (eg: "origin/pr/9/head").
and I didn't use github hooks
A post-receive hook in GitHub would post to any listening service any received commit.
It isn't limited to a particular branch.
However, Jenkins can be set to monitor a specific branch.
Unless, as mentioned in "How can I make Jenkins CI with git trigger on pushes to master?", you configure your Jenkins CI to Poll from GitHub (in which case, it will listen to said Github hook, instead of doing a git pull on a specific branch.
The GitHub pull request builder plugin mentioned by the OP Coombesy 's answer is one other way to make Jenkins poll GitHub.