Launched: Auto Deployment with Deploy API and GitHub Action 🤖

Introduction

The Deploy API allows you to deploy your project outside of Holistics, making integrating with CI/CD workflows easier. This integration unlocks the full potential of an “as-code” approach, enhancing automation and scalability. This is useful for scenarios like:

  • Auto deploying the latest update after merging PR into the master branch, by integrating Deploy API with the CICD workflow.

  • Auto deploying the latest update after new changes are pushed to master branch.

CICD Workflow Integration

Besides the Deploy API, we also provide a GitHub Action that makes it easy to integrate the deployment with your workflow.

Here is a demo of Auto Deployment with Deploy API and GitHub Action

Example GitHub Action config

name: Deploy AML

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
    types:
      - closed

jobs:
  deploy-aml:
    if: github.event.pull_request.merged == true || github.event_name == 'push'
    runs-on: ubuntu-latest

    env:
      HOLISTICS_API_KEY: ${{ secrets.HOLISTICS_API_KEY }}
      HOLISTICS_HOST: 'https://secure.holistics.io'

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

      - name: Deploy AML
        uses: holistics/[email protected]

We believe this update will enhance your workflow with Holistics. As always, we appreciate your feedback and support!

For more information, please refer to our public doc here: Auto Deployment with Deploy API | Holistics Docs (4.0)

5 Likes

Hello!

We just attempted the feature as recommended with github actions and believe we got it working, thank you so much for this, we’re really excited! :tada:

Once small thing we noticed though, when we used the proposed action flow as described in the post above, a PR being merged to master in github seemed to trigger 2 jobs, one for both the PR closed event (which is actually listed as running against the source branch rather than master when you go to the actions tab) and the other for the push of the new commit to master. A couple questions on that:

  • Is there any concern about the duplicate jobs creating an issue (ex. a race condition or something else), or is this relatively safe?
  • If we switch to JUST trigger on pushes to master branch, are there any events that this is likely to miss that the pull_request event would catch? What’s the reason for having both triggers?

Thank you in advance for the help!

Best,
Anya