Have you read T9456

@chad thanks for pointing, I just did, I've looked at the uber plugin before, but for our transition, I wanted to know if any of what I was asking above could be possible before we start entirely relying on that plugin. Also, have you seen that issue with harbormaster.sendmessage previously?

What response are you expecting? The method returns void (meaning "no data") and that's a "success" response (no error occurred).

@epriestley Ah, I see! I thought there was some error that's not being printed. I was expecting something like "message sent". Thanks for clearing that.

@chad @epriestley So, before closing this task, I have a question about how exactly harbormaster listens for messages, I have a build plan that makes a post call to jenkins with some parameters, the response (in the message log) appears to be the head response from jenkins server

Server: nginx/1.2.4
2	Date: Wed, 30 Sep 2015 00:36:58 GMT
3	Content-Length: 0
4	Location: http://10.21.42.131/queue/item/72/
5	Connection: keep-alive
6	X-Content-Type-Options: nosniff
7	Set-Cookie: JSESSIONID.9a9706df=1s6zk8yhj6ggc1wtjv17yqmov0;Path=/;HttpOnly
8	Expires: Thu, 01 Jan 1970 00:00:00 GMT

And the buildable is marked as a failure!
is it because harbormaster didn't receive a sendmessage? or am I doing something wrong?

@chad @epriestley got my setup working with sending messages about the builds via 'work' type result to harbormaster.sendmessage but still seeing the build's status as 'Failed' and the same log..
I'm not running any unit tests locally and no unit.engine is specified in my .arcconfig.. is that the reason?

To summarize,
arc diff -> linting done locally, no unit test engine specified -> herald rule kicking off a harbormaster build plan waiting for message -> jenkins job kicked off by harbormaster (harbormaster seems to mark the build as failure at this point, immediately) -> jenkins job responds with 'type':'work' for the build target -> I can see that in unit test results on the revision.

only problem being the build status for the above stated build plan is marked as 'failure'

I would really really appreciate any help in understanding why the build plan is marked as failure.

We fail if the server returns an HTTP status other than 200, exactly. Since it's returning a "Location" header, it's probably returning a 3xx status alongside it. The behavior you describe is consistent with the HTTP request returning a non-200 status.

@epriestley thanks of the immediate response, looks like jenkins is sending back a 201 Created. I can try to mask it as a 200 but do you think there is value in allowing 2xx status codes on harbormaster's side?

The build step will probably let you configure that eventually, but I don't expect to change that any time in the near future.

ah, i see!
I got too excited and created D14200

no worries! thanks for all the help @epriestley

@epriestley Any jenkins job that has to be built with parameters returns a 201 created, https://issues.jenkins-ci.org/browse/JENKINS-22849
it is turning out to be difficult to make it return 200 to a client even with a reverse proxy in front. Just wanted to know if you'd like to reconsider the decision to support 2xx or at the least, 201?
I wonder how @sectioneight's plugin works around this.

Although the return code check against exactly 200 has always been there, integration with jenkins was working as expected before rPd735c7adf2d5897d3ae08f3aba12774030c0d3b1

After I updated earlier this week, all my builds started failing, but jenkins is sending a "pass" response:

In the Harbormaster Build panel, the following information is shown:

When: Completed at Tue, Sep 29, 8:38 AM · Built instantly
Status: Failed

Messages:

454 jasonrumney pass Tue, Sep 29, 8:44 AM

Even though the Harbormaster task is set to wait for a response, it does not seem to be waiting any more based on those times, while before it was waiting despite the 201 status returned from jenkins.

It seems the change from setting the result to FAIL to throwing an exception in the case where the server does not return 200 is skipping some code after the call that was overriding the result to WAITING in the case where a build was set to wait for result. Probably this was a bug in the case where the result was already set to fail.

An easy fix will be to accept all 200 - 206 return codes, which should be valid as they are all variants on "request accepted and complete".

Aren't 2xx statuses considered "success" in HTTP protocol, despite values of "xx"?

So theoretically code instead of:

 if ($status->getStatusCode() != 200) {
      throw new HarbormasterBuildFailureException();
}

should be:

 if ($status->getStatusCode() < 200 || $status->getStatusCode() >= 300)  {
      throw new HarbormasterBuildFailureException();
}

As of now, I'm hacking around this by having a flask app that listens to harbormaster calls and in turn calls jenkins before returning 200 to harbormaster.

@epriestley thank you so much!