How to properly create and test new workflows

I am new to github actions and I’ve been investigating whether or not it’s possible to move my Azure pipelines over to github. I confess, though, I’m stuck on some fairly basic tasks.

How do I go about testing and debugging the creation of the workflow file itself? Are there some best practices that would help me out?

Here’s a scenario to illustrate my problem:
I have an action that should build and test my dotnet code on each PR to my master or devel branch. It should also do this when a push is made to the devel and master branches. And if the run is for the master and devel branch, then I want it to create build artifacts.
So, I created a workflow that I think should do everything I want. I saved it to a new branch and created a PR. However, that PR does not trigger a workflow run. AND even if it did, it would not run the steps to create the artifacts since it’s only a PR and not a merge.

I usually have a few syntax mistakes and various fixes that have to be addressed when creating a pipeline, so I doubt I have the action perfect the first time around, but how do I easily test this? I’ve been reading documentation, but haven’t seen anything that addresses this issue.

Any advice from anyone would be welcome?
Thanks.

1 Like

Hello @egeyer. Welcome to the community!

There are several different potential approaches here. What works best for you is going to depend on a lot of factors and any ideas I suggest won’t be the be-all-and-end-all, so I hope that others will chime in with their best practices as well!

It sounds like the situation you’re in is that you have a well-established project that’s in production and you can’t simply start merging things in simply to test your GitHub Actions workflows. If that’s the case, you could consider creating a second copy of the repository and testing your workflows there. As long as you disable anything in your workflows that makes external changes (such as uploading artifacts to a central server or updating documentation sites or what-have-you), then this approach should allow you to test things with relative impunity.

Additionally, something that I’ve tried to do more of lately is instead of trying to do everything in the workflow file, create reusable modular Actions that I can test more like regular code separate from any workflow or production project. I’ve found that by making these modular Actions, the whole workflow can be reasoned about more easily and the logic understood better.

I hope that helps! Let us know if you have more questions.

1 Like

Hi @egeyer,
You could try to add branch filter for push and pull_request event in the workflow, and in the step to create build artifacts , you could add if conditional to confirm if the workflow is triggered by push event or pull_request event.
Please see my example workflow:

on: 
  push:
    branches:
      - 'master'
      - 'devel'
  pull_request:
    branches:
      - 'master'
      - 'devel'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    #ddd
    - uses: actions/checkout@v2
    - name: Dump GitHub context
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: echo "$GITHUB_CONTEXT" 
    - name: step hello
      run: |
        echo hello
        
    - name: create artifacts
      run: echo artifacts
      if: github.event_name == 'push' && ( github.ref == 'refs/heads/master' || github.ref == 'refs/heads/devel' )
1 Like