Using Environments without creating deployment automatically

[LaurenzReitsam]

Current Situation:
Every pipeline step that uses environments automatically creates a new deployment. This seems to be wanted behavior.

Problem
Access to an environment might be also needed for other reasons than deployments. Like running integration tests (deployment already done; we want to assure correct behavior of latest deployment)

Possible Solution
Can we add an option to avoid an automatic deployment always when using environment?
An idea might be to set an environment variable like AUTO_DEPLOYMENT=false.

Additional information

• GitLab has option to specify what kind of action is done within environment

[flobernd]

The exact same thing bugs me as well.

I would even go one step further and decouple the deployments from environments completely by default.

Imho every workflow should be able to be a deployment task - or not. Instead of using the environment to determine this, we could just have another string key in the yaml (similar to the "concurrency" key).

[civitaspo]

I have the same problem. I want to limit deployments only on protected branches after the pull request has been merged, but I want to use environment secrets at the time of the pull request as well. Specifically, it is a case of executing terraform plan in a pull request and terraform apply in an action that runs on a protected branch after the pull request is merged. Currently, it is not possible to limit the deployment to a protected branch while sharing the environment secrets to actions on non-protected branches.

[jameslounds]

Temporary Workaround: use github's api in actions to delete all deployments which match our sha.
We can use the github-script action., which lets us use octokit.js in the action
Our job will need the deployments: write permission.

- name: Delete Previous deployments
        uses: actions/github-script@v6
        with:
          script: |
            const deployments = await github.rest.repos.listDeployments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              sha: context.sha
            });
            await Promise.all(
              deployments.data.map(async (deployment) => {
                # we can only delete inactive deployments, so let's deactivate them first
                await github.rest.repos.createDeploymentStatus({ 
                  owner: context.repo.owner, 
                  repo: context.repo.repo, 
                  deployment_id: deployment.id, 
                  state: 'inactive' 
                });
                return github.rest.repos.deleteDeployment({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  deployment_id: deployment.id
                });
              })
            );

[tianhuil]

Same: would love to be able to disable with a yaml property like - autodeploy: false.

[berkeli]

Temporary Workaround: use github's api in actions to delete all deployments which match our sha. We can use the github-script action., which lets us use octokit.js in the action Our job will need the deployments: write permission.

- name: Delete Previous deployments
        uses: actions/github-script@v6
        with:
          script: |
            const deployments = await github.rest.repos.listDeployments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              sha: context.sha
            });
            await Promise.all(
              deployments.data.map(async (deployment) => {
                # we can only delete inactive deployments, so let's deactivate them first
                await github.rest.repos.createDeploymentStatus({ 
                  owner: context.repo.owner, 
                  repo: context.repo.repo, 
                  deployment_id: deployment.id, 
                  state: 'inactive' 
                });
                return github.rest.repos.deleteDeployment({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  deployment_id: deployment.id
                });
              })
            );

Works nicely, but the following line needs to be removed for it to work:

# we can only delete inactive deployments, so let's deactivate them first

[yusijs]

This would be great, my pull requests currently look like this:

We use environments for builds etc as well (secrets), so it becomes a mess very quickly. Being able to specify the environment at the top level (before the jobs) might also help a bit, but ideally it would be possible to do something like this in the job definition:

environment:
  name: dev
  url: https://github.com
  deployment: false

[ftzi]

@jameslounds what about creating an Action for it in the Marketplace?

[constgen]

We already have a ton of actions for deployment creation and status update. It is not a necessary to create a new one. But my issue now is when I use a custom deployment actions for more control of deployment status, I have a duplicated deployment in history. Having one of these would help:

• A variable in Github Context with deployment_id, so actions can check that environment was used in configuration and reuse existing deployment_id instead of creating a new one.
• Option to disable automatic deployment report when environment is defined in a job

[nagibyro]

Just FYI if you're using @jameslounds workaround for workflows that run for pull requests, you need to modify the script, since the GITHUB_SHA is the last merge commit not the head commit that just got pushed to the PR branch (which is what the deployments are created with). You can add the github.event.pull_request.head.sha as an environment variable to the action:

  delete_github_deployments:
    runs-on: ubuntu-latest
    needs: run_tests
    if: ${{ always() }}
    steps:
      - name: Delete Previous deployments
        uses: actions/github-script@v6
        env:
          GITHUB_SHA_HEAD: ${{ github.event.pull_request.head.sha }}
        with:
          script: |
            const { GITHUB_SHA_HEAD } = process.env
            const deployments = await github.rest.repos.listDeployments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              sha: GITHUB_SHA_HEAD
            });
            await Promise.all(
              deployments.data.map(async (deployment) => {
                await github.rest.repos.createDeploymentStatus({ 
                  owner: context.repo.owner, 
                  repo: context.repo.repo, 
                  deployment_id: deployment.id, 
                  state: 'inactive' 
                });
                return github.rest.repos.deleteDeployment({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  deployment_id: deployment.id
                });
              })
            );

We had to add this as a job that ran at the end of the workflow instead of the last step of other jobs because the deployment didn't seem to always be deleted in that case. So you still see the message on the PR's till the whole pipeline runs which can still be confusing for folks but seems like the best you can do for now.

[ftzi]

@nagibyro Many thanks! So if I have 4 .yaml files, I add this to their end?

Yes! But probably just putting it on the longest one would do it. Maybe there is a way to create a workflow that runs after all of them?

[kylebjordahl]

I ran into a similar version of this where our deploy workflows are manually triggered (either via UI or GH CLI) and we supply a specific release ref to deploy; the deployments created by the workflow show the current state of main as the deployed ref, when in fact they should show the ref of the specified release.

I made this Action to handle our case, but feel free to fork it for your own purposes; hope it helps others until this gets sorted