Integrating existing CI infrastructure


#1

Hi,

I’m currently checking how I could integrate our CI system into phabricator pre-publish-review. After reading a lot of stuff I came to this conclusion:

  • Creating a herald rule which triggers a new build for a review request.
  • Because in the phabricator approach this have not been published to any git repo,
    a shell script would use “arc patch” to apply the changes and triggers the build.
    (Today this happens using git hooks, because we only build published changes)
  • The result would be inserted into the review request using the phabricator json API.
    This could be just comment or a rejectchanges. This somehow could mitigate the issue (T731),
    that multiple approvers are required.

I read also something about harbour, build plans and drydock, but I don’t really understand it yet.
Is this an own CI system, or could be used also to integrate existing ones?

Any suggestions?

Background: Our CI system is very similar to Travis-CI. It uses docker based images, which can be configured via a checked-in file .ci.yml. The build is triggered via a git hook, which informs all build hosts via IRC about changed branches. Because our cross-platform C/C++ code is built using CMake, we are using CDash to view build results including units tests, coverage analysis, valgrind, etc. CDash also sends email notifications.
I’m not sure how this fits into harbour.


#2

Harbormaster is the CI system for Phabricator.
In many places, all it does is “start a build on the existing CI system”, and the existing CI can report back errors/logs/test results to the HM build, which then shows up in a nice UI in the Revision.

In https://secure.phabricator.com/T9456, the upstream added support specifically for Circle CI - it sounds like you can use a similar setup. See https://secure.phabricator.com/book/phabricator/article/harbormaster/ for the general docs, and I think there are more detailed instructions when you build a Harbormaster build plan that uses Circle CI.

Basically, your build plan will have “make http request” step which will trigger the build, with “wait for response”, and your CI will use harbormaster.sendmessage endpoint to report its results.

If you setup “Staging” in the repository (repo -> management -> Staging Area), than arc diff will also push the code as git tags, which will allow you to get it without arc.


#3

thx a lot, this looks like a good solution.
Are there any examples available for the sensmessage part?


#4

I’ve now a working stagin area and can trigger a HTTP Request when a review request is created.
but the HTTP POSt contains no parameter about what to build.

I used “Run Plan Manually” and specified the “D2” as test review.
the Buildstep is configured to run “http://localhost:8080/cgi-bin/demo.cgi” using HTTP POST,
and this gets called. But all info about repo, branch or D2 is missing.

this is all I get:

POST /cgi-bin/demo.cgi HTTP/1.1
Host: localhost:8080
Accept: */*
Content-Length: 0
Content-Type: application/x-www-form-urlencoded

How can I configure it to transmit all necessary information?


#5

Did you put any of the variables into the url

image

e.g.

http://localhost:8000/demo?commit={buildable.commit}&who={initiator.phid}&repo=${repository.callsign}


#6

thanks, I was already searching for such variables, but couldn’t find them in the doc.

Now I found them. You must scroll down. They a below the edit form, so I didn’t see them :wink: