Introduction

GitHub releases are often used to distribute new versions of a project, but what happens if you want to prevent a release from being visible to the public before your workflow or build completes? 

This situation can arise when you want to ensure that only fully tested and built versions of your project are made public. Exposing incomplete or incorrect releases could cause confusion for your users and create potential issues in your software.

In this blog, we'll show you how to prevent GitHub releases from being visible until your workflow (such as CI/CD) is finished, ensuring that only the final, stable version of your project is shown to the public.

Understanding the Problem

GitHub releases allow project maintainers to create downloadable versions of their software, along with release notes and asset attachments. 

However, in certain cases, you may not want a release to be visible to the public until a complete workflow, such as a build or testing process, has been finished. Exposing an incomplete release might result in issues, such as incomplete binaries, missing files, or incorrect versioning.

While GitHub doesn’t provide a built-in way to prevent a release from being visible until a workflow completes, there are methods to achieve this behavior, using GitHub Actions and some careful release management.

How to Prevent GitHub Release from Being Visible Until Workflow Completes

There are a few approaches you can take to achieve this:

1. Use GitHub Actions with draft Releases

The easiest and most straightforward way to manage releases is by using draft releases in combination with GitHub Actions. A draft release is not visible to the public until you mark it as published.

Workflow with Draft Release:

1. Create the Draft Release: When your GitHub Actions workflow runs (usually after your code is built and tested), it can create a draft release, which won't be visible to the public.

2. Update Workflow to Create a Draft Release: In your GitHub Actions workflow, you can add a step to create a draft release. For instance, you can use the actions/create-release action, but with the draft flag set to true:

- name: Create GitHub Release
  uses: actions/create-release@v1
  with:
    tag_name: ${{ github.ref }}
    release_name: "Release ${{ github.ref }}"
    draft: true
    body: "Description of the release"
    token: ${{ secrets.GITHUB_TOKEN }}

3. Publish the Release After Workflow Completes: Once your build and tests are successful, you can update the draft release to make it public using a subsequent GitHub Actions step. For example:

- name: Publish the Draft Release
  uses: actions/github-script@v4
  with:
    script: |
      const release = await github.repos.getReleaseByTag({
        owner: context.repo.owner,
        repo: context.repo.repo,
        tag: '${{ github.ref }}'
      });
      await github.repos.updateRelease({
        owner: context.repo.owner,
        repo: context.repo.repo,
        release_id: release.data.id,
        draft: false
      });

4. Complete Workflow Example:

Here’s a full example of how your GitHub Actions YAML file could look:

name: Build and Release Workflow

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Create Draft Release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.ref }}
          release_name: "Release ${{ github.ref }}"
          draft: true
          body: "Description of the release"
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Publish Release
        if: success()
        uses: actions/github-script@v4
        with:
          script: |
            const release = await github.repos.getReleaseByTag({
              owner: context.repo.owner,
              repo: context.repo.repo,
              tag: '${{ github.ref }}'
            });
            await github.repos.updateRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              release_id: release.data.id,
              draft: false
            });

2. Conditional Release Publishing

You can set conditions for when a release should be published. For example, if your project includes integration tests, you can use the status of those tests to determine when the release is visible.

Example with Conditions:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      # Checkout, install dependencies, and run tests
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Run tests
        run: npm test

  release:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - name: Create Draft Release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.ref }}
          release_name: "Release ${{ github.ref }}"
          draft: true
          body: "Release Notes"
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Publish Release if Tests Pass
        if: success()  # Only publish if tests have passed
        uses: actions/github-script@v4
        with:
          script: |
            const release = await github.repos.getReleaseByTag({
              owner: context.repo.owner,
              repo: context.repo.repo,
              tag: '${{ github.ref }}'
            });
            await github.repos.updateRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              release_id: release.data.id,
              draft: false
            });

3. Use a Manual Trigger for Release Visibility

In some cases, you might want to completely control when a release becomes visible. In such scenarios, you can set the release as a draft and manually trigger the publishing after all necessary checks and validations have been completed.

You can set this up in your CI/CD pipeline and trigger the publishing using a webhook or manual intervention.

Conclusion

Preventing GitHub releases from being visible until a workflow completes can be easily managed with GitHub Actions. By creating draft releases and programmatically controlling when the release is published, you can ensure that only the final, stable version of your project is made public.

Using GitHub Actions, you can integrate your build, test, and release pipeline seamlessly, while also preventing premature release exposure. By following the steps outlined in this blog, you can make your release process more controlled and reliable.