Pausing is very cost expensive

[Aras Abbasi]

Please add a more prominent warning, that using this action is pausing a github runner. So if you use private repos, you get heavily billed.

[cristianmadularu]

Please add a more prominent warning, that using this action is pausing a github runner. So if you use private repos, you get heavily billed.

Do you know if using the native support for gating environments would also incur additional costs? (other than the more expensive monthly subscription cost). Thanks!

[Aras Abbasi]

@cristianmadularu
What do you mean with gating environment?
Are you referring to this?
https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#wait-timer

If so I have no clue. We have a github enterprise account, so we dont use wait-timers.

[cristianmadularu]

I was refering to this
https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments

It is only available with github enterprise (which we do not have) and I was looking for alternatives - which is what led me to this potential workaround (the manual-approval action).

[Aras Abbasi]

I can not test it rn.

You can use following rule of thumb:

For every job (not step) started a new github runner is spawned. And from that moment the billing starts. This action is a step in a job runner. And the step stops on some dubios events. Thats why it is expensive in private repos.

You can test that reviewing deployments functionality. If you see in the action overview, that a job is running, it means that you are creating billing minutes.

Afaik, the deployment reviewing function does not start a job but waits till somebody approved the run of the ci cd pipeline.

What is your use case? Maybe you dont need to use this action at all. E.g. trigger manually the deployment workflows by adding a label to the pr.

name: Deploy on Staging and run tests

on:
  pull_request_target:
    types: [labeled]

jobs:
  deploy-staging-test:
    if: ${{ github.event.label.name == 'test-staging' }}
    runs-on: ubuntu-latest
    steps:
      ...

[cristianmadularu]

Thank you for your time!

My use case is the following:

1. We want to have multiple environments: Development, Staging, Production.
2. Each time a PR is merged to main (following code reviews, etc.), we want to deploy our software in Dev. We could have mutiple deployments per day for example.
3. Once we are happy with a particular deployment, we want to promomote that to Staging and perform more tests, soak it for a while and, once we are happy with it, we want to promote it to Production.
4. While we are soaking into Stage, we continue to develop and merge PRs into main (and update our Dev deployment), but we do not want those deployments to automatically go to Stage (or Prod).
5. Ideally, we also want to control which team member is allowed to promote to Stage and Production.

One easy/natural way of doing that would be to use the support GitHub provives for reviewing environements where you can add various team members in charge with reviewing the deployments. Unfortunatelly, that is, for some reason, only available when using the Enterprise subscription (which is about 5 times more expensive than the GitHub Teams sub that we are using).

[Aras Abbasi]

Well i see some issues regarding the codebase that strongly bound to the deployed systems.
Everything gets merged into the main branch. And basically you say, that you have to keep track of the commit hashes of the deployed code.
My gut tells me, that this means, that your main branch, which should always contain stable code, is actually potentially containing non-stable code.

It makes imho more sense to have the clean main branch, which only contains the production code. Then you have a development branch, were all the new code is merged and deployed to dev environment. And a staging branch, were the staging commits gets merged and the code deployed to staging commit. Then you could actually use branch protection rules and set also necessary reviewers for those branches.

But still. The deployment and the code base are still too strong coupled. What if I want to deploy another branch onto dev? Is it not possible? Or what if I want to remove a specific commit? Do I now have to cherrypick?

[cristianmadularu]

Those are valid points and we actually initailly looked at using protected branches. We looked at both using main for prod and a dedicated branch for dev (and one for stage) and also at having main for dev (as we have it now) and using protected branches for other environments (stage and prod) but, after some back and forth we decided to not go that way.

One thing that we are doing is tag every commit to main so we can then choose what to deploy on each env by selecting the desired tag. What we are currently looking at is creating some simple workflows that would allow us to select which version of the software (generated and tagged when a PR is merged into main) to deploy to which environment.
Something like this

The idea is that this would allow us to both deploy the next version to the desired env when ready and also quicky revert it if anything goes wrong. (that is the theory anyway)

PS: we would add the tag as an argument that the user would enter when executing the workflow, similar to the one for selecting the environment.

[Aras Abbasi]

Maybe its cheaper to write a github app with probot in javascript. You create a technical user called madularubot, so that you can make something like @madularubot deploy v0.0.1 staging
And your bot reads all the issue events of your repo/org and checks for such calls for him.
If you want to make it more secure, you could write e.g. a totp check in your deploy script. So your bot knows the totp secret and your repo has the totp secret. Your deploy script checks for the given totp and if it is not correct, rejects the workflow run.

BUt this would have the benefit, that you could trigger the deployment from issues and pull requests. Or you just do it in pull requests and if you have not enough approvals you call for deployment and the madularubot could start the deployment.

So what you can do is, automatically deploy the dev stuff always to dev, as it does not need any special approvals. And if you want to deploy on staging, you create a new issue, and write in the body of the issue, as mentioned above: "@madularubot deploy v0.0.1 staging" and madularubot reacts on this and writes "x amount of approvals needed. Following users are requested for an approval: @ cristianmadularu @ uzlopak ...". And then you have to comment with "@madularubot lgtm" or you need to make a thumbs up on the comment. Who knows. If enough approvals are there then madularubot triggers the deployment by dispatching the workflow per rest api call.