GitHub Enterprise – workflows automation and reusability

Many organizations have succeeded in stabilizing their CI/CD process. They have implemented a stable deployment process using GitHub Actions workflows, which can be used for future projects and shared with other teams. However, this can lead to duplication and lack of reusability, resulting in more time spent on automation implementation.

At Formula5, we understand these challenges based on our experience. That’s why we not only help organizations stabilize their CI/CD automation but also ensure that the implementations can be reused across the organization’s teams.

If you’re interested in learning more about our holistic approach to GitHub Enterprise implementation, please refer to our GitHub Enterprise Adoption Framework.

The benefits of templates reusability

Using templates in GitHub Enterprise has several benefits in terms of reusability. One major advantage is the support for reusing GitHub Actions workflows. Instead of copying and pasting from one workflow to another, you can create reusable workflows, which helps avoid duplication. This simplifies the maintenance of workflows and allows new workflows to be created more quickly by building on the work of other teams.

Moreover, reusing workflows promotes best practices within the organization. Teams can use workflows that have already been well-designed, tested, and proven to be effective, thus saving time and effort. By building up a library of reusable workflows, your organization can centrally maintain and share them with different teams.

In order to make automation templates more reusable and available for different teams, GitHub provides helpful features and approaches that we can discuss.

GitHub Reusable Actions and Workflows

GitHub Actions provides organizations with the ability to automate build, test, and deployment pipelines. Depending on the solution architecture and technology stack of the application, it is possible to implement various types of GitHub Actions workflows that consist of multiple steps.

To ensure that workflows can be utilized across different projects and repositories on GitHub, organizations can make use of GitHub Actions Reusable Workflows. To give a concrete example, imagine that your organization has multiple .NET applications, and different teams are building them all in the same way. In such a situation, it is possible to create a single reusable workflow instead of copying and pasting workflows between different projects and repositories.

Here’s an example of a reusable action:

name: Build and publish Azure Function App

on:
  workflow_call:
    inputs:
      AZURE_FUNCAPP_NAME:
        required: true
        type: string
      PROJECT_FILE_PATH:
        required: true
        type: string
      AZURE_FUNCTIONAPP_PACKAGE_PATH: 
        type: string
    secrets:
      LIVE_NOTIFICATIONS_AZURE_FUNCAPP_PUBLISH_PROFILE:
        required: true

jobs:
  build-and-deploy-azure-function-app:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v2
      - name: Build Function App
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '6.0.x'
      - name: Install dependencies
        run: dotnet restore PROJECT_FILE_PATH/*.csproj
      - name: Build
        run: dotnet build PROJECT_FILE_PATH/*.csproj --configuration Release --no-restore --output ./func-app-packages
      - name: Test
        run: dotnet test PROJECT_FILE_PATH/*.csproj --no-restore --verbosity normal


      - name: Deploy Function App to Azure
        uses: Azure/functions-action@v1
        with: 
          app-name: ${{ env.AZURE_FUNCAPP_NAME }}
          publish-profile: ${{ secrets.LIVE_NOTIFICATIONS_AZURE_FUNCAPP_PUBLISH_PROFILE  }}
          package: '${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}/func-app-packages'

The above workflow can be then used in another workflow by directly referencing it in a job section:

name: "Another workflow"

on:
  push:
    branches: [ main ]

jobs:
  deploy:
  uses:
    formula5/actions/.github/workflows/deploy-az-function-app.yml@1

It’s worth noting that actions and reusable workflows stored in private repositories can be shared with other private repositories within the same organization, user account, or enterprise. Reusable workflows can define outputs that extract outcomes from executed steps, making it easy to pass data to the “main” workflow.

Share at the GitHub Enterprise Account level

In the case where the GitHub Organization is owned by a GitHub Enterprise Account, it’s possible to share actions and reusable workflows within the enterprise without publishing them publicly. This can be achieved by allowing GitHub Actions workflows to access an internal or private repository that contains the action or reusable workflow. This means that any actions or reusable workflows stored in the internal or private repository can be used in workflows defined in other internal or private repositories owned by the GitHub Enterprise Account.

GitHub Composite Actions

GitHub Composite Actions allow the combination of multiple actions into a single action that can be shared and inserted into any GitHub Actions Workflow. This approach enables the refactoring of long YAML workflow files into smaller, more reusable files that can be utilized across different teams and projects.

Here’s an example of a composite action:

name: "Publish to Docker"
description: "Pushes built artifacts to Docker"

inputs:
  registry_username:
    description: “Username for image registry”
    required: true
  registry_password:
    description: “Password for image registry”
    required: true

runs:
  using: "composite"
  steps:
      - uses: docker/setup-buildx-action@v1

      - uses: docker/login-action@v1
        with:
          username: ${{inputs.registry_username}}
          password: ${{inputs.registry_password}}

      - uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: user/app:latest

Then above composite action can be referenced in other repositories, as a single action:

on: [push]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: my-org/publish-docker@v1
        with:
          registry_username: ${{secrets.REGISTRY_USERNAME}}
          registry_password: ${{secrets.REGISTRY_PASSWORD}}
Main differences between reusable workflows and composite actions

Reusable workflows offer the ability to have multiple jobs with references to the same reusable workflow, which is a powerful tool for reusability. Unlike composite actions, reusable workflows do not require individual folders for each workflow.

A good example to highlight the difference between the two and their use case scenarios is when a job needs to run on a specific runner or machine. In such a situation, reusable workflows must be used since composite actions run inside the job of the main workflow. Composite actions are intended to be more isolated and generic.

Here are some main differences between reusable workflows and composite actions:

By utilizing GitHub Reusable Workflows and Composite Actions, we can significantly increase reusability across teams in our enterprise. Reusable workflows allow us to easily share workflows between repositories, while composite actions enable us to combine multiple actions into a single action that can be shared and inserted into any GitHub Actions Workflow.

Using these features not only saves time and effort in automation implementation but also promotes best practices and consistency across teams. They can be used to build up a library of reusable workflows and actions that can be centrally maintained and shared within the organization, leading to more efficient and effective automation processes.

GitHub Starter Workflows

To facilitate the sharing of workflows across different teams in the organization, GitHub Starter Workflows can be a useful tool. Users with write access to the organization’s .github repository can create starter workflows, which can be used as a starting point for building custom workflows or used without any modifications. This not only saves time but also promotes consistency and best practices across different teams in the organization.

For organizations using GitHub Enterprise Cloud, starter workflows can be used to create workflows in private repositories. By defining Reusable Workflows and Composite Actions and using them in Starter Workflows, teams in the organization can easily reuse or leverage them to implement other workflows much faster. This approach allows for a more efficient and streamlined automation process within the organization.

Summary

In conclusion, promoting workflow reuse within an organization not only saves time and effort in automation implementation but also promotes best practices and consistency across teams. By building a library of reusable workflows, organizations can centrally maintain and share them, leading to more efficient and effective automation processes.

It’s worth noting that the options presented in this article are just a small part of the larger Enterprise Adoption Framework. At Formula5, we are always ready to help organizations make informed decisions at any level of their GitHub adoption journey.

Written By

Innovation Lead for Microsoft Cloud Services

Related Posts

We are using cookies to give you the best experience. You can find out more about which cookies we are using or switch them off in privacy settings.
AcceptPrivacy Settings

GDPR

  • We value your privacy

We value your privacy

We use cookies to enhance your browsing experience, serve personalized ads or content, and analyze our traffic. By clicking “Accept All”, you consent to our use of cookies.

Let’s make your vision a reality!

Want to discuss my work or a challenge you’re facing?  Leave your details and I’ll get back to you!

Popup Form