Understanding GitHub Actions and Deployments

I am trying to build an all-github workflow for CI and CD using Actions and the Deployments API. The CI part is done, and I am now facing a couple of confusing aspects when tackling the CD side of things.

1. How to run a workflow only when deployment environment == ‘production’?

I am planning on having a different workflow for staging and production. Intuitively, I was hoping I can do something like this:

    types: [production]

or better yet - something close to “on push tags”:

  ## this is available
  # push:
  # tags: ['v[0-9].[0-9]+.[0-9]+*']

  ## this is not available
    environments: [stage]

But according to the Events that trigger workflows documentation there are no additional arguments (e.g. “types”) to that event. So how am I expected to run this workflow only if it is on a specific environment (e.g. “stage”)? 

I hope the answer is not using some “if: conditionals”… in the same way that I can filter branches / tags on push, I hope to be able filter environments on deployment.

2. (Auto-) updating deployment status

When triggering a deployment using the API, I can see the workflow being triggered, and the deployment added to the Environments tab, as expected: Untitled.png

What was less expected, is that status remains at “Pending” after the workflow completed successfully.

Does this mean I have to take care of manually updating the status, from my workflow script, using the API? This seems way too tedious - go out using an API and access token, just to send message back in, where everything is already authorized and authenticated.

I understand it if this is just a temporary situation, since until recently, deployments were meant to execute external services - but now with GitHub Actions, I expected a workflow that runs on deployment, to automatically update the status, in the same way that CI (automated tests) automatically update the PR status.

If this is not the case, or not planned - I would love to have an official GitHub Action or “echo ::pattern::” to do that.

I found an external action that updates the deployment status, but it feels very dirty to use a user-built action for a concept so native to GitHub.

Also - if there is no document that outlines (by example) how to use GitHub Actions with deployment, I think there should be one (I could not find any) - I think these two concepts belong tightly together.

Thanks in advance if anyone can enlighten me.


Hi DannyBen, 

Thank you for your questions. 

  1. Currently deployment event doesn’t support any types. If you could not accept adding if condition to your job, I am afraid that you have to submit a feedback ticket in the Feedback form for GitHub Actions.

  2. According to this image, Github needs to receive a update Deployment Status request after the deploy completed. Yes, for now, when you use Github Actions workflow to run your CD, you need to update the status from your workflow script using the API.  The external action you mentioned above is also using create a deployment status API.  https://developer.github.com/v3/repos/deployments/#create-a-deployment-status

  deployment status.png

1 Like

Thank you, that is dissapointing.

I saw the chart you posted, but now, in my view, that “3rd Party” is becoming GitHub Actions in the workflow I was planning:


I will submit a feedback form.

1 Like

i’m second to env specific deployment event to avoid if condition at job level.

we use self-hosted runner, for access control, when deploy to production, we use dedicate runner with restrict access (AWS IAM roles) to production account.

1 Like

Same here, our company would benefit from it too :slight_smile:


We too are trying to use github actions as our CI. So far I’m enjoying the fresh approach github has taken but did face this same limitation.

I was wanting to create different workflow files for each of our deployment environments. dev, staging and prod.

The idea behind a distinct workflow for each (rather then one with 3 jobs) is that we can have a status badge for each that links to the last run of that workflow file and thus deployment - all displayed in our title readme.md.

Would love a filter on deployments.
Makes so much sense!

+1 on needing a deployment plan per environment.