Status integrity between Outgoing Webhooks and Builds Status

Archive Website Issues
, ,
1

I don’t know if this is an issue or an evolution but I would like to raise an unexpected behaviour.

We try to enable outgoing webhooks on our online environment. But we notice statuses are different between outgoing webhooks and build api.

Based on Build API, statuses are :

  • status=0: Not finished yet.
  • status=1: Build finished, with success (status_text=success).
  • status=2: Build finished, with error (status_text=error).
  • status=3: Build was aborted (status_text=aborted).

Whereas when I configure outgoing webhooks, my server only receives:

  • status=0: Not finished yet + Build was aborted
  • status=1: Build finished, with success
  • status=2: Build finished, with error

So aborted status does not seem to be handled by outgoing webhook.

Moreover, in outgoing webhook response, there is not status_text field whereas it could be relevant especially for status 0 because there is not is_on_hold field.

1 Like
2

Hi @jessyhanzo,

Thanks for reporting! :wink:

Just to be sure: is the issue that you don’t even get webhooks of aborted builds, or that you receive that but with status=2 instead of status=3?

3

Thanks for your reply :slight_smile:

My Server receives aborted event but with status=0.

1 Like
4

Got it, that’s definitely a bug and we’ll fix it ASAP, thanks for reporting! :wink:

On hold status is not sent right now as the webhook is about the “trigger” event of the build, where it might not be decided whether the build will be on hold or will start right away. Additionally even if the build is on-hold at the point when the webhook message is configured it might switch to running before the webhook would be actually delivered (e.g. a couple of seconds later).

Is there a specific reason why you’d need the on-hold info?

1 Like
5

Got it, that’s definitely a bug and we’ll fix it ASAP, thanks for reporting! :wink:

:sunglasses:

On hold status is not sent right now as the webhook is about the “trigger” (…)

I understand what you mean. For now, we don’t really have a relevant use case for an on-hold event… I will open a feature request later if I find one :slight_smile:.

FYI, we use webhooks for sending messages to Workplace build’s requesters and letting them know the build status. On-hold would have been interesting for watching out their request. Obviously, we can also write a CRON which requesting Build API each X minutes. Anyway, this feature is not really important.

1 Like
6

Got it! For the on-hold status, I’d rather send a separate webhook event, in addition to the “build triggered” one (which you can say is “on hold” or at least “build not started yet”) an additional “build started” event. If I’m right that would provide a solution for this use case. Without the second event, simply including “on hold” status in the “triggered” event would be misleading most likely, as “triggered” is really just that, that the build is “registered”, it might start right after that or be delayed for longer (e.g. due to on hold queueing).

If you agree feel free to create a #feature-request, or if I missed something just let me know! :wink:

1 Like
7

Hey @jessyhanzo,

Thanks again for the issue report :slightly_smiling_face: We’ve discovered the source of the issue and made a fix for that.

Happy building :wink:

2 Likes
8

This topic was automatically closed after 13 days. New replies are no longer allowed.