We have a project on Snap CI but since it's going away we have to switch to another tool.
GoCD is our favorite but there is an important feature I am wondering if it's supported: Branch tracking.
Snap CI supports branch tracking which is currently enabled in our project: 'This repository has automatic branch tracking enabled for all branches starting with ***':
I tried to set up GoCD to do exactly this. But I couldn't find a way to achieve this behavior. The only thing I found was the feature branch / pull request plugin.
Do you know if such a feature is supported or how I have to configure the FB/PR plugin?
Thanks!
We wanted to do something similar and were faced with the same problem. In the end, we couldn't get direct branch tracking, but created a GoCD API client that created pipelines from a template, and the branch of Git material is set to a parameter (e.g. #branch). The client gets run manually when branches are created, but it could quite easily be adapted to run from hooks to automate it.
Related
For some projects I use the CI service drone.io. Currently every time I make a commit to any of my branches, drone.io launches a build process. In some situations I consider this a waste of energy and resources and thus want to prevent unnecessary builds. Such situations are e.g.: Changed typos in README.md, working on a new feature and thereby committing some immature code
As far as I know there is no branch-wise configuration. However, this thread in the support forum indicates that via the .drone.yml some fine tuning seems possible. But still I do not know how to enable/disable builds on branch-level.
Alternatively, using some special tag in the commit message would also work for me.
You can use the where trigger to target a particular branch only, see where for the documentation.
Using where & branch you can trigger drone builds for changes to e.g. master only to cut down on unwanted builds. Try adding a block like this:
trigger:
branch:
- master
Teamcity 10 offers new feature storing project settings in version control
What is the best practice to follow in terms of storing these settings?
Keep it in the same repo where code resides?
Put it into separate repo?
We have put it into separate Git repository called teamcity-settings after having it in repository with some other stuff for continuous integration. The problem with having it together with something else was that it makes too much "noise" in git history, since every TeamCity build configuration update is doing a commit.
So my suggestion - let TeamCity settings live it's own life in version control. :)
I'm currently trying to setup some code analysis for my team however I found our release process does not mesh well with the tools I have looked into (CodeClimate and SonarQube). Both tools require a default branch to track the state or "grade" of your repository over time. They watch the default branch and analyze pull requests to that branch. However, our current release process involves a new branch for each release which we merge into master after the branch is released. We could use master as our default branch but we would not see the analysis until after the code is out which is not ideal. As I am not in a position to change our process, I am tasked with finding a tool or work around to get an analysis tool to work with our process. The only work around I could think of is two pull requests. One to the release branch as usual, and another to master just to trigger the analysis. The master PR would then be closed once the issues found in the analysis are fixed. This is far from ideal and I come to my favorite forum looking for help and experience.
Code is in Github.
Primary language to analyze is PHP, bonus languages are CSS, JS, and Java.
It looks like Codacy could be a good alternative.
You can enable the analysis on all the branches of your project. All the pull requests to an analysed branch will be analysed, even if it's not the default branch.
It supports all the required languages: PHP, JS, CSS, Java and more. It also has a nice auto-comment integration with Github to help you save more time in code reviews.
What I want to do:
I want to set up Continuous Integration with Team City for a project that's hosted on GitHub.
What's Currently Working
I'm properly connected to GitHub. Commits, pushing, etc etc all seem to be fine.
TeamCity is set up and I can kick off a build which will run and run my unit tests, but...
What's Not Working
When I do a TeamCity build, it looks like it's pulling down code from GitHub before doing the build or running unit tests. I want to trigger a TC build when I do a commit, before it does the push to GitHub. I don't really want it to pull any code out of GitHub before running the TC build. This doesn't seem to be working at all.
I've set up a BuildTrigger which is a VCS Trigger. I've checked the box that says Trigger a Build on Each Check-in. I added a rule to the BuildTrigger with the VCS (Github) source and my username.
When I do a commit, I don't notice TC doing anything. When I then push the commit to GitHub, TC doesn't do anything either. I see no builds queuing or anything like that.
Any clues on what I'm doing incorrectly?
Thanks!
Have you looked at TeamCity's pre-tested commit feature? It doesn't work exactly as you described you would like your workflow to operate, but it might be useful. I've used it with Subversion in the past and it works pretty well, I haven't used it with Git but JetBrains state it also works with Git.
However, the most common workflow for Git is to create feature/bugfix branches for everything you do, which allows you to commit and push freely, and merge to master when you are ready. GitHub makes the merge (and optional code review) step painless and TeamCity has built-in support to automatically build branches, see the TeamCity documentation on feature branches for specific details it provides.
We'd like to implement CI using TeamCity.
We use Git for source control and would like to make use of the "pre tested commits" or "personal builds" feature of TeamCity.
Does anyone have experience with the VS plugin for Teamcity?
As far as I've seen, it only supports Subversion, no word about Git.
Anyone used this setup with any success?
As explained in Pre-tested “Commits” using Git by JoergM, you can emulate a solution similar to the TeamCity6.x "Personal builds on branches", by using personal repos:
.
There is one central Git-repository that only contains pre-tested changes. I call this “Green Repository” because it should only contain changes that lead to green builds.
Every developer pulls from this repository but nobody is allowed to push to it.
Instead everybody has a personal repository (think fork if you were on GitHub). The CI Server watches those personal repositories. After a commit it starts the compile and test. If that was successful it pushes the changes to the Green Repository.
JoergM adds:
The question is whether we will continue using our own solution or switch to the new feature of Teamcity.
So far I can’t see any advantage of the Teamcity feature.
With our solution we are even more flexible in regard of branch design.
This kind of setup is similar to what I described in "What is the cleverest use of source repository that you have ever seen?".
TeamCity 6.5 has new feature: remote run on a branch. It works for Git and Mercurial and does not require IDE, see more here: http://confluence.jetbrains.net/display/TCD65/Branch+Remote+Run+Trigger
Note that support for Git branches has been considerably improved in TeamCity 7.1. In my opinion, this is far better than the personal build feature.
The relevant docs are available here: http://confluence.jetbrains.net/display/TCD7/Working+with+Feature+Branches