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.
Related
I'm looking for a solution to dynamically select a branch to build in the Azure pipeline. I have Azure Repos Git where I select project, repository and default branch. I would like to be able to select branch based on a variable.
What I'm trying now is to use the Command Line task and fire a git checkout command (e.g. branch is a variable):
git checkout $(branch)
I can't confirm it working yet but still I confirm it works but I feel that there is a better option than checking out default branch and then switching branch with the command line.
Update:
If you want to have single pipeline that can build different branches (version branches) for different branches, you could just specify them in the trigger of branch filters. This will not build all branches.
The branch you select in build definition is just the default branch used when you Queue New Build manually. OTOH the build trigger establish which branch to download, e.g. if the build has been triggered by a git push on branch develop then that is the one checkout'ed and built. Take a look at this link: Get the sources from the branch that triggered the build in Team Services
Besides, you could disable the default get source step.Then use you own powershell script and git command to get source code manually(just what you want) and check out branch, finally build based on your variable.
For YAML, to disable the default "Get Sources" just specify none in
the checkout:
checkout: none
For UI, please refer my reply in this question:
Is it able to ignore/disable the first step Get source in vNext Build?
Assuming you're choosing the default branch. That doesn't mean that
it's the only branch that can be built by that build definition.
You can choose which branches to monitor for CI (on the Triggers tab,
you can add multiple branch filters to represent the branches you wish
to build on commit), and the appropriate branch will be checked out
when the build is triggered. You can also choose an alternate branch
when manually queuing the build.
Source Link: Get Sources from multiple branches
If you want to dynamically select default branch as below, this is not available at present.
This is the branch that you want to be the default when you manually
queue this build. If you set a scheduled trigger for the build, this
is the branch from which your build will get the latest sources.
The default branch has no bearing when the build is triggered
through continuous integration (CI). Usually you'll set this to be
the same as the default branch of the repository (for example,
"master").
There is a related user voice here: When triggering a build, use the same branch as the trigger build. You could kindly vote up and track the process.
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.
We use an internally hosted github server for our SCM, Jenkins for our CI and Git-Flow (via maven's jgitflow plugin) for our branching strategy.
I have a Jenkins build job set up such that it takes the git branch as a parameter and then can check-out and build the correct branch based on what was selected.
.....
.....
.....
What I would like - is to automatically trigger the BASE_JOB to build only the branch that's been pushed. So far, I have been unable to find any way to do this.
If I set up to build when changes are pushed to github, then the job will simply rebuild whatever the last built branch was regardless of the branch that's been pushed.
I've seen some plugins for Jenkins that will auto-generate template jobs when new branches are created - but I think it is over-kill to necessitate having a job per currently active branch.
Is there a way to pass a branch parameter to the "Build when a change is pushed to GitHub"? Or some other way to work around this apparent limitation?
Thanks!
Check with these settings and see if it works.
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've been trying to find a way to build multiple projects when pushing(syncing) to a PR on github. We have multiple projects(projectA or projectB) that are dependant on one main project(let's call it mainProject).
When changing the signature of a method in mainProject (that are used in projectA), I would need Jenkins to build mainProject first, then build projectA.
The build environment is fine. What I need is to fetch the corresponding branch on the other dependant projects.
So let's say I
Modify projectA and push to branch name 3333
Change a signature in mainProject and push to branch name 3333 .
Open PR in github for projectA and mainProject both with branch name 3333 to development branch.
Whenever I sync my previously created PR on projectA, I would like to jenkins to :
Fetch mainProject 3333 and fetch projectA 3333.
From there, i'll manage the building...
We are using
Github PR plugin builder
Github plugin
I see there is a Add repository box, but I can't seem to get it to fetch the mainProject.
The Repository URL is the ssh .git url from our github repository.
I've also seen this plugin :
Multiple SCMs Plugin (can't post the link because I don't have enough reputation!)
Does anyone had the chance to try that?
Thanx in advance.