I would like to to see all builds from a specific build type. To get them I am using this URL:
[team-city]/httpAuth/app/rest/buildTypes/id:[build-type]/builds
However, this only shows builds from the default branch. In my project I am using git-flow, so I do not have a single default branch. I have a lot branches, per feature/version. How do I get (by REST) builds for those branches?
I was just looking at a similar issue, i resolved it by including:
branch:(unspecified:any)
in this context:
/guestAuth/app/rest/builds/?locator=status:SUCCESS,number:<mybuildnumber>,branch:(unspecified:any)
Where mybuildnumber is self explanatory. This URL found a specific build i was looking for from non-default branch
Related
I'm using AWS COdeBuild with GitHub on several projects, and I noticed today that it doesn't work anymore. Something's broken, and I don't know what.
I have configured CB to automatically build when a PR is updated. It used to work fine, but now it shows "Expected", without any link toward the CodeBuild build. And, on CodeBuild interface, there isn't any build running.
It's as if the commit on the PR didn't trigger any build on CodeBuild.
Considering everything was working fine, and I don't believe I've made any change to the GitHub nor CodeBuild configuration. So, what could be the reason for the build not to be triggered? What should I look for?
Manually triggering a build from CodeBuild UI works fine, and is properly sync with the PR.
The reason was both stupid and simple: I had renamed the GitHub repository using a different case.
I.e: 'myproject' > 'MyProject'
Changing the source in CodeBuild to load the new source (with updated case) fixed it:
https://github.com/UnlyEd/MyProject.git
Simple, stupid, and so easy to miss. GitHub handles very nicely those name changes and there is no need to change the local git config, as it treats older names as aliases. But CodeBuild must somehow check for the source repository name and doesn't handle case changes.
We used to have a big project that had SonarQube analysis run on it for every pull-request on GitHub. Everything worked fine.
Then we did some refactoring, and split the code into separate projects. Since the code is related, the repo is still the same. But, instead of running just one build+analysis we run multiple ones per pull-request.
Everything else works fine, except that the SonarQube GitHub plugin writes the problems found in the first build, then removes them in the second build and so on. So I get an email about problems in the first build, but when I go and look at the PR in GitHub, it's all green and no messages anywhere.
Optimally I would like to specify to SonarQube GH plugin that these builds should be handled as separate in the PR, but I haven't found a way to do that yet.
What you are trying to achieve is not possible with the SonarQube GitHub plugin. If you want PR analysis back, you have 2 ways:
Either you gather those projects under the same umbrella, making them modules of a top project
Or you extract them in different repositories
The best solution depends on how your "new" projects are coupled to each other. If they have the same lifecycle (~ the same versioning scheme), then it's best to gather them under a top project. If not (i.e. they can be released independently with different versions), then moving them to dedicated repositories would be the best approach.
It is possible, but requires a complex setup:
- A SonarQube project for each language.
- A Github user for each language
- In each SonarQube project, under the General Settings -> Pull Requests, set a different access token to post back to github for each project.
Now you will have 2 different commenters, one for each project.
I'm using Visual Studio Team Services to build my project which is stored in GitHub (here). The master branch contains multiple projects which make up the solution. Amongst those are a WebAPI project and a Cordova project. I need to build those using two separate build definitions in VSTS.
Previously I had set-up my build definition and used the branch filters to filter on what had been pushed to the repo. For instance:
master/src/API
This worked, but it doesn't any more. It seems as if the underlying code has changed. A filter of 'master' still works and I understand how this feature is probably meant to filter specifically on branches and maybe not on folders within the branch?
It's not a huge problem, but at this time all of my builds will trigger with every check-in, even if nothing changed in the meantime for that source code. So I'm not wondering what a good solution for this issue would be:
Put every project in it's own branch. Seems like a workaround
Some other filter option or maybe another syntax or something?
Leave it as it and don't worry about the extra builds (but that itches, you know...)
Anyone running a similar set-up?
Path filters is not supported for VSTS GitHub CI Build, it is available for Git CI Build on VSTS. You can vote this user voice: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/15140571-enable-continuous-integration-path-filters-for-git
The workaround is as you said that put every project in its own branch.
I have a CI build that is setup in TeamCity that will trigger when a pull request is made in BitBucket (git). It currently builds against the source branch of the pull request but it would be more meaningful if it could build the merged pull request.
My research has left me with the following possible solutions:
Script run as part of build - rather not do it this way if possible
Server/agent plugin - not found enough documentation to figure out if this is possible
Has anyone done this before in TeamCity or have suggestions on how I can achieve it?
Update: (based on John Hoerr answer)
Alternate solution - forget about TeamCity doing the merge, use BitBucket web hooks to create a merged branch like github does and follow John Hoerr's answer.
Add a Branch Specification refs/pull-requests/*/merge to the project's VCS Root. This will cause TeamCity to monitor merged output of pull requests for the default branch.
It sounds to me like the functionality you're looking for is provided via the 'Remote Run' feature of TeamCity. This is basically a personal build with the merged sources and the target merge branch.
https://confluence.jetbrains.com/display/TCD8/Branch+Remote+Run+Trigger
"These branches are regular version control branches and TeamCity does not manage them (i.e. if you no longer need the branch you would need to delete the branch using regular version control means).
By default TeamCity triggers a personal build for the user detected in the last commit of the branch. You might also specify TeamCity user in the name of the branch. To do that use a placeholder TEAMCITY_USERNAME in the pattern and your TeamCity username in the name of the branch, for example pattern remote-run/TEAMCITY_USERNAME/* will match a branch remote-run/joe/my_feature and start a personal build for the TeamCity user joe (if such user exists)."
Then setup a custom "Pull Request Created" Webhook in Bitbucket.
https://confluence.atlassian.com/display/BITBUCKET/Tutorial%3A+Create+and+Trigger+a+Webhook
So for your particular use case with BitBucket integration, you could utilize the WebHook you create, and then have a shell / bash script (depending on your TeamCity Server OS) that runs the remote run git commands automatically, which will in turn automatically trigger the TeamCity Remote Run CI build on your server. You'll then be able to go to the TeamCity UI, +HEAD:remote-run/my_feature branch, and view the Remote Run results on a per-feature basis, and be confident in the build results of the code you merge to your main line of code.
Seems that BitBucket/Stash creates branches for pull requests under:
refs/pull-requests//from
You should be able to setup a remote run for that location, either by the Teamcity run-from-branch feature, or by a http post receive hook in BitBucket/Stash.
You can also use this plugin : https://github.com/ArcBees/teamcity-plugins/wiki/Configuring-Bitbucket-Pull-Requests-Plugin
(Full disclosure : I'm the main contributor :P, and I use it every day)
I have created a build configuration in TeamCity (v8.0.1) to automatically build my Github pull requests by setting my VCS branch specification to +:refs/pull/(*/merge) (I followed this blog post).
TeamCity is picking up new pull requests and changes to existing pull requests just fine, however it is kicking off multiple builds per change when I would expect it to only perform a single build.
For example, I pushed up two commits to an existing pull request which resulted in 8 builds being executed by TeamCity. When I look at the changes for each of the builds the change graph is identical except for the commit hash of the pull request's build (at least I think that is what it is), e.g.
I have confirmed that Per-checkin Triggering is disabled in the Build Trigger configuration. I have also confirmed that we are not using any of Github's TeamCity hooks.
Any ideas what the problem might be?
I'm not sure what could cause this, but have you tried to turn on "Quiet Period"
http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers