Github action for "pull_request" as well as "push"?

[philj404]

Thanks for creating this library! I has saved me from myself several times already.

Recently someone had a good idea for my library and submitted a pull request for it ( philj404/SimpleSerialShell#12 ).

They followed good practices on GitHub and created a fork of my repository, made their changes and submitted their pull request back to me.

When I enabled the action (for first time contributors) the pull request did not run aunit tests on their submission. The build checks ran as I expected.

I think the reason the aunit tests did not run is that the GitHub Action is set up to only run on "push". Since the changes were pushed to a fork, they did not run on "push". Since aunit_tests.yml only runs on "push", creating the pull request did not trigger a run.

So, I have a couple questions:

• Does it even make sense to run unit tests on a pull request from a code fork (as a pre-check)?
• I made a copy of aunit_tests.yml for my library's GitHub action. (Since it is a copy I have not kept up to date with later improvements.) I have modified my copy to run on pull requests. Would it make sense for the master example of aunit_tests.yml to run on pull requests by default?

Thanks again for providing such a useful way to run unit tests.

[bxparks]

I think you are asking if the EpoxyDuino/.github/workflows/aunit_tests.yml file should be changed from:

on: [push] 

to

on: [push, pull_request] 

?

I'm not a serious GitHub Actions expert, but I think it is a recent change that the workflow no longer runs on the forked repo? If I recall, it was something to do with security. Before, I think I remember people complaining about the workflow test failures on their forks when they tried to send changes to some of my libraries. So now we have to manually click on a confirmation box to allow the workflow to run, (which from a security point of view, seems kinda useless because I'm always going to click "Allow"). And that also means that even with pull_request, a new contributor sending a PR would not trigger a GitHub workflow, because we have to manually approve it.

The other problem I personally have with adding pull_request is that I actually create PR's to myself, when I merge my develop branch into my master branch just before I create a new release. I don't want to trigger redundant workflows, because some of my validation tests can take a substantial amount of time, e.g. validation for my AceTime library can take over 5 minutes.

So instead of changing to [push, pull_request], I would be ok with adding a comment to that file, something like this:

# Trigger on 'push'. Optional, consider adding trigger on 'pull_request':
# https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull_request
on: [push]

[bxparks]

Done with
297cf6b

[philj404]

I am not very familiar with GitHub Actions either. So yes, I was wondering if adding pull_request to the list of triggers would be the right thing.
Basically the side effect without pull_request is that I need to create/push a local copy of the pull request branch from the fork before any tests will run. A local branch is probably a good idea anyway.

Like you I also saw that the workflows will run multiple times with multiple reasons for a trigger. It was somewhat distracting, but my tests don't take very long (yet).

Thank you for adding a comment for the EpoxyDuino workflow! A comment is probably the best way to do it.

It can be difficult to know where to look for "master templates" when I make a local copy of a file -- but now I know a good example is in .../bxparks/EpoxyDuino/.github/workflows/aunit_tests.yml

[bxparks]

It can be difficult to know where to look for "master templates" when I make a local copy of a file -- but now I know a good example is in .../bxparks/EpoxyDuino/.github/workflows/aunit_tests.yml

I give links to many of my own YAML files here:
https://github.com/bxparks/EpoxyDuino#ContinuousIntegration

[bxparks]

I came across a solution to the duplicate workflow iterations with [push, pull_request] here:
https://blog.fleetdm.com/4-tips-for-github-actions-usability-2-debugging-4c0c920adfde

Copied here for reference when the above link goes offline:

Instead, consider running only on pushes to the default branch (main/master):

on:
  push:
    branches:
    - main
  pull_request:

[philj404]

There are a lot of useful ideas for how to use github actions in that link!

... But for my small library I am not ready for much complexity yet.
I think I understand the basics of how the action works now. I can call my library uses the action "good enough", since it is not getting in my way yet.
I can focus on Arduino/C++ issues.
Later, when the redundant builds start slowing everything down, I can come back to this.