Github Actions failure handling during deployment

Given a workflow that is triggered on = “deployment”  I would like to both deploy and update the deployment-api. From what I gather I guess these are my alternatives:

  1. Deploy action does a http call to deployments api on failure/success

  2. Deploy action saves deploy result in a file and uses exit code 0 for success. The sequential action reads from that file and does a http call to deployments api.

  3. Use checks api or a Github App to notify Deployments API on failure/success

1 I don’t like because it is hard to reuse code. reuses code, but complicates deploy actions.  would be great, but how?

Anyone doing something similar? All the examples I find, that does deployment, never updates the deployment api. Most of them just does deploy automatically if the branch is the master branch.

Thank you for taking the time to write your feedback! Hopefully, someone else here has a similar workflow and can share their experience. In the meanwhile,  I’ve taken your feedback and passed it along to the appropriate teams. 

1 Like

I found a functional solution for this, going along with option number 1.

What I found to be working quite well, was to create a generic action that adds shell scripts which later actions can reuse. The scripts strive to be as minimal as possible, and has only one dependency, and that is curl

It worked pretty well for a couple of projects that we are testing on, and the code is made available at

I’d much appreciate comments or even better - pull requests :slight_smile:


I’ve been trying to come up with a solution for this on and off for the past couple weeks.

Based on my experience I came up with two ideas but it would require help from GitHub.

  1. It seems like it would be great if an action was allowed to run regardless if the action it depended on succeeded or failed. If something like this we’re possible i believe we could have a simple deployment status action that sends the update based on the status of the previous actions, but allowing that would obviously be a flag/option the user enables.

  2. Since the workflow is kicked off on deployment events maybe GitHub should fire back the deployment status per action automagically for us. If an action succeeds fire a success action, but if one fails fire off a failure.

What do you think about those? I personally like #2 because it just seems cleaner to not have your workflow with a bunch of status actions. Also, in your case your actions don’t have to worry about firing off deployment statuses they just do their job.

I also wonder how we can send a request like that in for consideration?


#1 Yes please :slight_smile:

#2 That was my initial thought also. But that’s was not how it is implemented to begin with. Maybe later down the line. I think it could be pretty clean. Although it might be difficult for the App that is subscribing to the events from the workflow to extract information that it would like to add to a deployment status event

I also wonder how we can send a request like that in for consideration?

I don’t quite know, seems like this is the place. Admins replies to discussions I see, and informs that they are taking the matter to the development team.

Hi @jerrylopez!

Thanks for the suggestion! While we don’t have an official place to submit feature requests, @judoole is correct that GitHub Staff does frequent the GitHub Community Forum and as admins and moderators, we do our best to capture this sort of feedback and share it with the teams who are in charge of designing and improving GitHub.

Speaking of which, I’ve passed your feedback on to the appropriate teams. I can’t promise if we will implement this suggestion or when we can make that happen, but we’re always looking for new solutions and if we do implement this feature, it will be announced in the GitHub changelog.


1 Like

Hey @judoole 👋🏽

This looks like a nice and simple solution until GitHub adds a tighter integration with their own Deployment API. Imho, as @jerrylopez pointed out, if an action is triggered by a deployment event, it would have be great if GitHub provided an option to update the deployment in question - automatically populating it with target url and description.

In the meanwhile, I’ve looked at your solution and got it working with SlashDeploy - a chatbot to manage deployments from Slack. I’ve created an aws-eb custom action, which uses your scripts and now I am finally getting deployment notifications into our Slack :raised_hands:t4:.

There is some room for improvement, so expect from me a PR that would populate log url and deployment description soon :wink:.


1 Like

Thanks @assimovt! And aws-eb looked great!

I’ve had a quick look at Slashdeploy recently, love the work you are doing! We are considering it to replace Hubot for deployments from Slack. Think I tried to register a couple of weeks ago, but I think it failed, probably because I’m don’t have owner-rights of the Unacast organization or something. Love that you can specify configuration within the repository.

For now, I’ve tested using the Github Slack integration for notifications. It is trying to add a deploy action in near future, it seems like. But I think it won’t be as feature friendly as Slashdeploy :slight_smile:

Btw, did you find a solution to the create a log_url to the action @assimovt? I also asked that in

Thx, @judoole It’s still in PoC as I can’t get the log URL and description of the deployment. Also, noticed you’ve bumped into a similar issue and tested that it’s not being exposed in ENV. I think we have to wait for that to come in from GitHub.

Regarding SlashDeploy registration failure - you should be able to request GitHub app installation from organization/repository admins. Mind dropping me an email to tair [at] getslashdeploy [com] so I could help you out? It’d be really awesome if Unacast benefited from all those features we’ve built to support team deployment workflow :wink:

@judoole Thanks for open sourcing github-deploy - it’s been really helpful to get our Slack + GitHub Actions + AWS Beanstalk deployments rolling. I’ve blogged about it  👉 check it out!


Thanks @assimovt, that was a nice write up as well!

On my todolist is todo a write up of my findings as well. Now I have a great blogpost to reference :) 

I ended up solving a very similar problem to this when building deliverybot ( This is the repo that I’m using to deploy to firebase from actions and set the correct deployment status:

It doesn’t try and automatically wrap anything just builds on top of if statement functionality in GitHub actions basically. If the previous state was failure() then we push a failure status.

1 Like

Nice @colinjfw !

We’ve rewritten the status action as well. Decided to use shell over node. Because I don’t particularly like that commiting of the node_modules