GitHub additional Status

My CircleCI jobs have authorizations to update my commit GitHub status (this is the way it manages to say when the CI passes). I would like to benefit from that authorization to add my own status from within my job. The main usage is that my CI job deploys a demo and I would like to add the fact that its ready and the final URL to the status. Is there a way to access the right GitHub API token that would allow to access the Statuses API please? https://developer.github.com/v3/repos/statuses/

Hello,

You could run curl commands against that endpoint from within your job to generate and update arbitrary statuses with URLs per commit. You can see an example in this job here. I’ve added a GitHub API token to my project envars called GITHUB_TOKEN which has repo status access. I use this to authorize POSTing to their status endpoint. Then if you look to the left of the commit message here at the top you’ll see a red x, and if you hover over it you’ll see the status that was generated from within the job, and the details link is clickable opening the page i’ve added in the request. Please disregard the commit message. I was having a bit of a moment.

Is that what you’re looking to achieve?

Hi Fernando, thanks for answering, and sorry about your moment :slight_smile:

Actually I’ve ended up doing the same thing, but would prefer not have to use a GITHUB_TOKEN: that token is personal whereas my CI is for a project. Also I’ve already authorized CircleCI somehow to do this kind of actions, so I wanted to benefit from that token.

I’m not sure there’s a way to expose that auth for use within the job. We inject SSH keys in the job to provide access to basic git operations with the repo. Any other auth, such as keys that would enable interacting with the GitHub API, are secured within our backend. Therefor you’ll need to use the auth options available for the GitHub API to interact with it. Which I believe is basic auth or using API tokens. I think some orgs will create a machine user account with generated tokens shared for the org in cases such as this, so interactions aren’t tied to an individuals personal account. If I discover a workaround here i’ll share it but I think the curl solution may be the best available option.