I tried continuous integration tools Travis CI, CircleCI and codeship, but found none of them provide support document for phabricator. Does anyone have ideas about how to do continuous integration (CI) with Phabricator?
I have done an integration with Travis-CI by adding post diff and land hooks to Phabricator to push diffs as branches to GitHub where Travis looks for branch updates. As far as I know, Travis-CI integrates only with GitHub, so if your main repo is there and Phabricator is pointing to it, it can be done.
If you want to take this approach, the place to start is with creating your own ArcanistConfiguration and overriding didRunWorkflow. See also how to create a new library. The API documentation is pretty good, but I had to go through some trial and error to get what I wanted. The Phabricator people are probably happy to answer questions.
You can also look into the Phabricator conduit differential.createcomment to script messages to diffs like so:
arc call-conduit --conduit="https://my.phabricator.com/" --arcrc-file="robot.arcrc" \
differential.createcomment <<EOF
{"revision_id":"1234","message":"Yer build done failed"}
EOF
Where robot.arcrc is an arcrc file with the credentials to push messages, and 1234 is the revision number. You would have to use the conduit API to get the revision number.
So, I think the answer is you may have to build your own custom solution depending on which CI integration for the CI tool you want to integrate with. And here's a discussion of Travis support for Phabricator.
Edit: Here's traphic, an example of extending arcanist to push diffs to branches on GitHub on arc diff and remove them on arc land. As Travis-CI looks for update from GitHub, it will build your diffs.
Side note: This is mostly a brain dump. I know good answers have more code examples and links are frowned on, but the question was pretty open ended and was looking for pointers, so I'm trying to be helpful.
If you are using Jenkins, the nice guys at Uber created a Jenkins Phabricator Differential plugin that makes it possible to really clean up your job configs (if you've already set them up using the links from zerodiff's post).
Might be worth noting that Phabricator's tool to do continuous integration (i.e. Harbormaster) is currently under development.
You can find this in a table in their comparison page. See http://phabricator.org/comparison/
Related
I've just started learning and using nativescript; everything seems alright and I'm making progress, but I haven't been able to find a solution for continuous delivery. (on push on master branch in bitbucket, I want to automatically make the build and distribute it).
I've tried appcenter from Microsoft (I used it before for Xamarin) but could not make it work.
I use bitrise (https://www.bitrise.io/). It integrates with bitbucket for CI and also offers scheduled builds. There are free plans available. Takes a little config to get working with NativeScript, but worth it so far.
I've searched for multiple solutions. I've retried with VS appcenter, there was an example or two on google(e.g. https://github.com/skhye05/nativescript-app-center ), but did not work for me.
I guess I'll close the ticket for now.
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.
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
I am referred to Hudson today.
I have heard about continuous integration before, but I have no idea what the heck is a ci-server.
Hudson is really easy to install in Ubuntu and in several minutes I managed to set up an instance of it.
But I don't quite understand the workflow of a ci-server, or how am I supposed to use it?
Please tell me if you have experience about ci, thanks in advance.
Edit:
I am currently using Mercurial as my SCM, and I wonder what is the right way to use it with Hudson.
I have installed the Mercurial Plugin of Hudson, and I create a new job with a local repository. When I commit in the repository the Hudson job is built with the latest version of my source code.
If what I used is a remote repository, what's the workflow like?
Is it something like the following?
Set up a Hudson job with the repository
Developer makes a local clone of the repository
Developer commit and push changes
The remote repository update with the incoming changeset
Run a Hudson build
There may be something I misunderstanded at all, please help me point it out.
Continuous Integration is the process of "integrating software" continuously i.e. as frequently as possible (ultimately after each set of changes) to avoid any big-bang integration and all subsequent problems by getting immediate feedback.
To implement Continuous Integration, you first need to automate the build of your software (where build means of course compiling sources, packaging them, but also compiling tests, running the tests, running quality checks, etc, anything that will help to get feedback on the health of your code). Then you need to trigger the build on the latest version of the sources on a particular event (a change in the repository, a temporal event), to generate reports and to send notifications upon failure (by mail, twitter, etc).
And this is precisely the responsibility of a CI engine: offering trigger mechanisms, being able to get the latest version of the sources, running the build, generating and publishing reports, sending notifications. CI engines do implement this.
And because running a build is CPU and Disk intensive, CI engines usually run on a dedicated machine (or even a farm of machines if you want to build lots of projects).
Back to your question now. Once you've got Hudson running, configure it (Manage Hudson > Configure System): setup the JDK, build tools, etc. Then setup an Hudson Job and follow the steps: configure the location of the source repository, the build tool, the trigger, a notification channel and you're done (you can do more complex things but that's a start).
For more details on the setup, check:
The official Use Hudson guide for more details. << START HERE
Continuous Integration with Hudson - Tutorial.
Spot defects early with Continuous Integration.
Martin Fowler's overview of continuous integration is one of the canonical references. In my opinion, using automation to make sure your code base is healthy is one of the most useful things that you can set up.
Update Sorry that I didn't have much time earlier to expand on my reply. #Pascal_Thivent is right that in order to effectively use CI, you need to be able to automate your builds, tests, etc. CI is actually a good forcing function for this. For me, it's one of those little warning flags if I start to think that it would be too painful to put a build into Hudson. It means that something is not quite right.
What I like about Hudson is that it's flexible enough to accommodate different workflows. We use it for both builds / unit tests and releases. And it eliminates a lot of the worry about certain release procedures only working in one person's environment.
What I don't like about Hudson is that it is occasionally unstable when new builds break plugins. I've had a couple of upgrades (2 out of 10 or so) go bad because of incompatibilities. I do two things now:
I never upgrade my team's Hudson server to the latest and greatest right away. I generally only upgrade when there are significant new features, or bug fixes.
I now have a basic Hudson instance set up with all my plugins on a virtual machine with some dummy builds that I fire up to test out any new upgrades before doing it on the public server.
These questions are for TeamCity users only
1) Is it possible to configure TeamCity to extract build artifact information based on your own your regular expressions? This is exactly what Pulse does here
2) Does TeamCity integrate with any task/bug tracking tool? like JIRA?
3) This question is for people who run static code analyzer only. A tool like PC-Lint/Visual Lint can generate XML reports. Can TeamCity be configured to parse these artifacts and generate a build failure?
4) I'm currently evaluating TeamCity right now...there community forum doesnt seem to be very active. For those who pay for support, how is Jetbrains support? Is it good? Atlassian seems to be much better.
TeamCity allows to get build artifacts with a Ant-based pattern. You can specify multiple patterns and set target directory for each pattern. Read more at http://www.jetbrains.net/confluence/display/TCD4/Build+Artifact
There is an integration which allows to link RF-3432 to the Jira issue. More advanced integration may appear in the next release of TC. Read more at http://www.jetbrains.net/confluence/display/TCD4/Mapping+External+Links+in+Comments
Only with custom plugin. Or your build process can send a specific "echo" message which will change build status and description.
OK, I'm JetBrainer. May be we don't response immediately, but we strive to answer forum questions ASAP. Paid customers also have e-mail support.
Hope this helps,
KIR
Disclaimer: I don't work for JetBrains! But I've worked with Pulse and TeamCity in my current job.
Build Artifacts: Yes, TeamCity will export artifacts that remain after a build. You can add define ant-style wildcard patterns to match files (the default pattern matches any files left in the root build directory). These files can be seen from the project view against each individual build.
You can use special service commands in a build script to immediately export artifacts along the way too, I do this for a code complexity tool that generates xml files, for which I've also defined a custom graph.
Bug Tracking: I don't have experience with this, but KIR pointed out some alternatives.
XML Parsing: You can control this with ant. I included a third-party tool called andariel in my build that can run XPaths across xml documents, then used service messages to export the result (in this case a count of methods exceeding a complexity limit) to be displayed in a custom graph.
I believe you could also publish the artifacts, provide TeamCity with an XSL to render the XML, and create an additional tab in your build results to display it (however I have not done this)
Tech Support: I've found the community forums to be pretty good, most questions I've had answered within a day or two by both civilians and Jetbrains employees, and I was using the free 'Professional' version.
I can only imagine that email support will be just as good if not better!
I am a little confused about this question because my use of TeamCity, TC (and I guess the design principles of TC) is to allow the build script (and not TC) to remain the correspondent of build imperatives.
In other words, if you need TeamCity to do something cool, just add that cool stuff in your build script either using an existing task in your build system or write one yourself.
TeamCity supports NAnt, MSBuild, Ant and am sure, any other build platform you can install on on the buildagents.
The only integration I will want TC or any other CI platform to have is source control integration with my choice of SC. The rest of the integration should be controlled by my build script. That way, I only configure my TC once at the beginning of project for each project and then, don't touch it ever again. In contrast, the build can change per version.
So, the indirect answer to your question is Yes, theoretically, through the build script.
Hope this helps.