epriestley wrote on 2014-04-25 22:27:52 (UTC)

We have feed.http-hooks (config, allows you to add webhooks) and feed.query (conduit API, for polling) but no socket-ish stream.

You can subclass PhabricatorSSHWorkflow to add a new SSH workflow as a local patch if you want to stick with stream-over-ssh, although I'd guess one of the above mechanisms is a better approach.

PhabricatorBotFeedNotificationHandler, which polls feed.query to push events through the chatbot, might be a good starting point if you want to poll.

qgil wrote on 2014-04-30 15:30:07 (UTC)

Moving to "Not critical for the RfC" because it is assumed that Phabricator will need to be plugged to our continuous integration process. If the RfC is approved, then we will need to define a technical plan before going anywhere.

Maybe we can skip Zuul altogether?

• Integrating Jenkins and Phabricator with Harbormaster
• Part 2: Update Phabricator Harbormaster build with Jenkins

Harbormaster is marked as "prototype" today, but maybe by the time we need it, it suits our needs? In any case, after searching a bit it is clear that we are not the only ones and neither the first ones needing to connect Phabricator with Jenkins.

<hashar> CI is not that hard, though we need Phabricator to emit events
<hashar> and write some code in Zuul to understand those events
<qgil> hashar, or maybe we can skip Zuul altogether? See the couple of links I just posted at https://phabricator.wikimedia.org/T31#6406
<hashar> potentially
<hashar> if Phabricator has the utilities to reimplement all the logic we have in Zuul (very very unlikely)
<hashar> I am 99% sure Harbormaster does not match Zuul feature set :(
<qgil> hashar, are the features to match documented anywhere?
<hashar> the most important one is the ability to gate changes together which has a few pages documentation on http://ci.openstack.org/zuul/gating.html
<hashar> if we have change A , B which are approved with a +2 , we trigger two set of jobs. The first set test A
<hashar> the second set test A + B together
<hashar> before A get merged. Zuul speculates that A will pass so it assumes it is fine to test B with A already being merged
<hashar> if A pass it is merged, and if A + B pass it is then merged. Ie you don't have to wait for A to be merged to run tests for B
<hashar> (and changes can be in different repositories)

Obviously, Antoine and Timo will be the people leading this decision. I haven't assigned it to them yet as (at least speaking for Antoine) we don't have time to commit to it right now.

Obviously! I don't think that Continuous Integration integration ;) is a key element of T560: Proof of concept of code review in Phabricator. It would be useful to have @hashar and @Krinkle in the loop to make sure that we are not making any decisions now that will hit us when someone starts working effectively on the CI part.

It would be also good to have a plan, which can be a rough plan now, and a bit more polished plan by the end of year. But still a plan. The actual work on CI is not expected to start before the checkpoint after the proof of concept and the blessing of the full code review migration plan at that point. Needless to say, such plan must take into consideration the availability of the people that needs to be involved for the tasks that we have agreed.

As Antoine mentioned, the plan to move away from Jenkins is one reason to keep an abstraction layer (e.g. middleware) between Phabricator and Zuul.

Another important reason is the need for security and authentication. Until we have sandboxed VM testing, it is crucial that only submitted code from trusted users is executed. Phabricator probably doesn't (and shouldn't have to) have a built-in mechanism for doing that. It would depend on the middleware instead (e.g. Zuul).

Flagging it with Continuous-Integration-Infrastructure, I think we will talk about it during our January 2015 team meeting / tech summit.

Just quoting this here so it's not lost. Regarding comments from Jenkins on build status:

In T103127#2081839, @hashar wrote:

One can send markup that would be interpreted by Phabricator. Ie icons from http://fortawesome.github.io/Font-Awesome/icons/

OK	{icon check color=green}
OK (non voting)	{icon info-circle color=green}
Failed (non voting)	{icon info-circle color=yellow}
Failed	{icon ban color=red}
Whatever else	{icon info-circle color=blue}

+1 to that, that would look nice ;)

@mmodell have you managed to get phabricator working with Zuul?

We are not using Zuul for now. Phabricator triggers jobs directly in Jenkins over its REST API.

@hashar but how do we view jobs like we could in Zuul please since I found it easy the way Zuul was layout. Since it showed all jobs running for that project. May we could get upstream to add the Zuul type showing projects with how long they have been running for and how long left and underneath it could show the tests running for that project like Zuul does including progress and linked to the job. Please.

Also how can we add jobs to phabricator for each repo. Like in Zuul we have layout.yaml which made it easy for people to add tests to there repo. We should probably do the same for phabricator please.