Best Practices for building Releases with Github Actions/Workflows

Viewed 687

We are currently looking into Github Actions (on Github Enterprise) and I was wondering if there are any recommendations on how to best build releases with Github Actions.

What we want to achieve:

  • Manually trigger/approve/"promote" a release in some way
  • build artifacts with clean semantic version, e.g. 1.2.3
  • build (non-release) snapshots with unique intermediate versions, e.g. 1.2.3-dev.14667+f39a61d (as created by Nebula Release plugin for Gradle builds)
  • tag the released commit
  • it is OK for us to build the code again for the release to get a proper release version (does not have to promote the exact same artifacts that have been built before)
  • optional: restrict releases to release and master branches

I have been experimenting with the Github Release feature and registered a build action to that event which then builds the created version. Below is a simplified version of that workflow:

name: Build Release

on:
  release:
    types: [ published ]

jobs:
  build:

    runs-on: [ self-hosted ]

    steps:
    - name: "Building release"
      run: echo Building release version ${{ github.event.release.tag_name }}
    - name: Build with Gradle
      run: ./gradlew build publish -Prelease.version=${{ github.event.release.tag_name }}

This way you can create a new release by creating a Github Release, add all the details and publish that. Then the build starts and creates the matching artifacts.

While that workflow is OK, I was wondering if there are any other best practices for building releases. I could not find any, and searches into this topic always lead to individual Github Actions, but not to higher-level discussions.

0 Answers
Related