REST API: Travis CI statuses don't appear in statuses API

I want to fetch all statuses for a given PR revision in my app, but it looks like statuses posted by Travis CI do not appear there. Taking this PR as example, the web GUI clearly reports 3 statuses (2 by Travis CI, and one unrelated). This output makes me assume that Travis correctly created the status via REST API call (is that assumption correct?)

However, when fetching the statuses via API ([1] -> [2]), the output of [2] clearly only reports the (2) statuses by the unrelated check, but no Travis CI status.

What’s going on there - am I missing something here, or is Travis faulty, or are the statuses filtered in some way?

[1] curl https://api.github.com/repos/hxtreme/tasks3/pulls/6
[2] curl https://api.github.com/repos/hXtreme/tasks3/statuses/7526d20a276f6554c1af8a78c9b21d4568dc707b

2 Likes

Hey @maniac103 – I’ve asked around about this, after failing to find an immediate answer, myself. It’s not immediately obvious why the API is returning only the pyup statuses in your PR draft.

Would you mind trying the same curl, but authorized with a PAT that has the repo scope for that repository? Our thought is, those Travis statuses may not be included in the public return.

Hey @maniac103! Apologies for the double-ping without your response, but I reached out to another staff member who helped clarify behavior.

In the UI, statuses and checks are shown together and basically look the same. In the API, they’re separate concepts. So, some of those things you see in the UI are statuses and some are checks.

In the API, you fetch them via different endpoints. For statuses you use:

https://docs.github.com/en/rest/reference/repos#statuses

…and for checks you use:

https://docs.github.com/en/rest/reference/checks#runs

I hope this clears up the confusion, but it’s very possible it’s added to the confusion!

If you have any additional questions, or concerns, hit us up and let us know!

Thanks a lot @nethgato - that clears it up … and no need to apologize for a useful answer :smiley:

I have a question regarding the response though: in the response, for each check run, there’s two fields (status and conclusion) which look like they’re an enumeration … what are the possible values for those?

(NB: For those ‘enum-like strings’ in responses, it would be great if the docs could list out their possible values!)

Hey @maniac103! Hope you had a great weekend. And a great long-weekend, if you’re in the States!

The docs should contain the values for status, which are:

The current status. Can be one of queued , in_progress , or completed .
Default: queued

…and for conclusion:

Required if you provide completed_at or a status of completed . The final conclusion of the check. Can be one of success , failure , neutral , cancelled , skipped , timed_out , or action_required . When the conclusion is action_required , additional details should be provided on the site specified by details_url . Note: Providing conclusion will automatically set the status parameter to completed . Only GitHub can change a check run conclusion to stale.