So just an FYI, I'm currently building a TeamCity Phabricator/Harbormaster Plugin that aims to:

• Receive a message from Harbormaster indicating build kickoff of a particular diff
• Plugin uses Conduit to apply patch on top of master and build
• As the build runs, status messages are continually sent back to Harbormaster via harbormaster.sendmessage, reporting specifically on unit test pass/fail
• After build finishes, send message to Harbormaster on pass/fail of build

The plugin is ~80% complete, just testing on my local instance of TeamCity.

In T9456#141036, @epriestley wrote:

I'm still just working through this with CircleCI support. No real headway yet, turnaround has been ~24+ hours every time so we're still just discussing the problem.

This is a blocker for us so we contacted Circle support. They advised making a feature request so they can see how much demand there is.
Go to Compatibility with Phabricator, log in, and click the Heart to "vote" for it.

If CircleCI can only build branches, we could theoretically add an option to have arc push to branches instead of tags, although this is a lot of work and complexity on our side to get around what seems like a relatively silly limitation in CircleCI, if the limitation actually exists. I can just poke at the API to see if I can figure out how to build tags, but if someone already has it working that's obviously easier.

FWIW this would be useful in repositories where users can push branches (and maybe only to certain regex-matching branch names) and not tags. coolstory

FWIW this would be useful in repositories where users can push branches (and maybe only to certain regex-matching branch names) and not tags.

Is there any technical reason users couldn't be permitted to also push tags matching a regex? Or is the barrier there purely regulatory (you need to appeal to a committee that meets once a month in a locked closet in the basement or whatever)?

In T9456#142404, @epriestley wrote:

Is there any technical reason users couldn't be permitted to also push tags matching a regex? Or is the barrier there purely regulatory (you need to appeal to a committee that meets once a month in a locked closet in the basement or whatever)?

There's no technical hurdle. I've worked in organizations where QA or Project Management own source repositories and builds and engineering runs its own tools; I'm reflecting that experience in my post. (Of course the theory that controlling the source controls the quality is pretty easy to knock down.) In that sort of situation exporting directly from a Phabricator-owned repository clone seems like the best story anyway.

Yeah -- that make sense, I'm just want to be mindful of how much complexity we're adding to the upstream in order to subvert barriers that have no technical reason to exist.

For example, Facebook once deployed Phabricator with half the machines in Oregon and half the machines in North Carolina, with an artificial 5 minute replication delay between them (see T1969). We declined to add upstream support to address this scenario.

I'm fully onboard with subverting these barriers and this is the primary means by which I accomplished useful work at Facebook, I just don't want this upstream to bear the costs now that we no longer need to. If a feature is useful on its own and subverts barriers, that's great. If it only subverts barriers, that's a harder sell.

Hey,

If anyone's following along here I figured out circleci support for phabricator and posted some of the details at https://discuss.circleci.com/t/compatibility-with-phabricator/183/8 A big issue for us, that I think could be an issue for other people, is that our phabricator instance is firewalled from the rest of the world so while phabricator can post out, circle cannot post in. To resolve this, I used AWS SQS as a message proxy in the middle.

When you guys think about integrating third party build systems, try to think about best ways people can approach it if their phabricator is behind a VPN from the external build system.

Now that I've ran with this a bit, the next cleanup for us is

1. Use harbormaster build hooks to trigger the build rather than github messages on phabricator diffs
2. Use a staging area repo that isn't the same one people are committing to because people are complaining about the temporary phabricator tags.

Is there any documentation on configuring Jenkins for commit builds (instead of differential builds)?

Currently we are trying to migrate from Drydock-hosted builds to Jenkins, and the Jenkins plugin provided by Uber only works for differential reviews. As we don't know Java, we can't patch this, and none of the other HTTP plugins I've tried actually run as a post-build step, so there's no way to make a HTTP request when the build fails.

I have a branch up that allows for non-differential builds to submit
harbormaster from Jenkins. I dropped it before the holidays since there
didn't seem to be much interest but can resurrect it if people are
interested:

https://github.com/uber/phabricator-jenkins-plugin/issues/108

Right now we're working around it by having another build plan called "Post results to Phabricator" which has phid and state parameters. This build plan then runs the following PowerShell on a Windows build agent to post the result:

Invoke-WebRequest -Uri https://.../api/harbormaster.sendmessage -Method Post -Body @{"api.token"="...";"buildTargetPHID"=$ENV:phid;"type"=$ENV:state}

Then we configure other build plans to use a trigger another build with parameters post-build step that looks like this:

Haven't been able to test if this works yet though because I need to upgrade the Phabricator AMI to support SHA2 SSL.

Not super-familiar with PowerShell. If the issue linked above would be helpful to you, could you please add your requirements there and we can coordinate getting it in the Uber plugin? (I'm the maintainer)

This ticket has a ton of subscribers so I'd like to minimize noise.

I would also express interest in Thoughtwork's go.cd: https://www.go.cd/

I know I am not entirely alone, cause this issue exists: https://github.com/gocd/gocd/issues/1576

According to CircleCI this really truly works now, so I'll see if I can push our integration forward shortly.

It seems that tag builds do not support build_parameters. We need to pass parameters, so this is blocked on them again.

https://discuss.circleci.com/t/compatibility-with-phabricator/183/11

I've updated D14284 + D14286 + D14288 for the new API and rebased them onto modern code.

CircleCI fixed build_parameters in their API so support is now in HEAD of master. There's probably some remaining work but it seems to work properly locally. Let us know if you run into issues with it.

@epriestley Configuring a test project with Phabricator and CircleCI, cannot understand what format should the staging area be in.

Tried bare GitHub URL of the project, tried adding /tag/<tag-name>, release/tag/<tag-name>— getting a {"message":"Tag not found"} in all cases.

What kind of format should the staging area URI be in?

Thanks.

The staging area is a Git remote that we'll push to, so it should be a valid target for git push <url> ....

For a GitHub repository, you can find the repository URLs on the main page in the textarea above the directory list:

Either the HTTPS or SSH URLs should work, although one may be preferable depending on how you normally authenticate in your environment. For example, for this repository:

https://github.com/epriestley/poems

...these are valid staging area URLs:

https://github.com/epriestley/poems.git
git@github.com:epriestley/poems.git

An alternate approach may be to run git remote show origin and then copy the Push URL. This will usually be the same as above and correct, although in rare cases it may not be.

(See also some discussion in T8238.)

While Changes doesn't list any caveats in the readme for https://github.com/dropbox/phabricator-changes, the readme for Changes itself seems to indicate that it's dead:

NOTICE: THIS REPO IS NO LONGER UPDATED

The related repos indicate that Dropbox no longer intends to provide this CI tool for public consumption, so it's probably worth removing it from consideration completely. Its components started being deprecated months ago: https://github.com/dropbox/changes-mesos-framework/commit/cbb2351d45b4231286a18e70e5fea039b121d0a4

So, does this mean that of the list of potentially-supportable CI solutions for use with Harbormaster today, Jenkins is the only available self-hosted open source option?

Looks like CircleCI will stop supporting the V1 API, which we use, in about 5 weeks: https://circleci.com/sunset1-0/

See T13188 for CircleCI 2.0. Upshot: they removed webhooks so we can no longer interact with them.