Getting newbie users to act

[dimaqq]

Act version

act version 0.2.26

Feature description

I try to use act every now and again and I find my efforts thwarted.
I think that the key lies in this chasm:

• using act on a new/epmty-ish public repo with simple actions is nice and easy
• using act on an existing private repo requires so much setup that I give up

The setup, I think falls into these categories:

1. github credentials
2. repo/org secrets, like docker repo
3. hairy events

1. Credentials

The git repos I typically work with have submodules, lfs, branches, releases, and some actions need these... I'm not clear if act will try to get these from local clone, maybe it's possible?

Some repo may need another, sibling repo to build, there's probably no generic way out.

Some steps pass the GHA secret into the container to build something, I've observed this with buildx and/or docker/build-push-action.

2. Secrets

If only pushing an artefact required this, that'd be easy. Sadly, someone starts their Dockerfile with FROM private/repo:tag and while I have an active docker login that allows me to do that, act runs the build in some isolated environment, and secret would have to be passed manually

3. Events

Almost every workflow I work with has restrictions on push: branches: ... or push: tags: .... Sometimes these are not trivial, e.g. some steps are skipped in some conditions.

This leaves me with a bifurcation: let the action run regardless, and focus on the "build/test" of the action; or try to create the correct event (not easy) to focus on the condition of the action, meaning validating/tweaking that the action is run under correct circumstances.

Ideas?

I wonder how these stumbling blocks can be addressed.

Would it be possible for act to scrape local token/secrets?

Maybe there could be an oauth app that can be added to github to provide these on demand?

Perhaps, simply listing the missing tokens/secrets would be enough?

Would it perhaps help if passing an event made it clear if the event triggers the workflow, and if so or if not, then why exactly?

Would it be possible to scrape past events from workflows previously ran on github?

[airtonix]

It's not entirely clear what you're asking for here, because skimming over this and then going back and reading it in detail still didn't give me a clear idea.

So I'll try to address what I think you're asking for.

The git repos I typically work with have submodules, lfs, branches, releases, and some actions need these... I'm not clear if act will try to get these from local clone, maybe it's possible?

it just copies your CWD into the container.

Some repo may need another, sibling repo to build, there's probably no generic way out.

you use actions/checkout with the repo param. it behaves the same way here right?

If only pushing an artefact required this, that'd be easy. Sadly, someone starts their Dockerfile with FROM private/repo:tag

  act {{event}} \
    -s GITHUB_TOKEN="$(gh auth token)"

so if your scenario requires more secrets, then you could (i'm using gopass here):

  act {{event}} \
    -s GITHUB_TOKEN="$(gh auth token)" \
    -s SOME_OTHER_PERSONAL_ACCESS_TOKEN="$(gopass show -o projects/one token-two)" \
    -s ANOTHER_PERSONAL_ACCESS_TOKEN="$(gopass show -o projects/one token-three)" \

This leaves me with a bifurcation: let the action run regardless, and focus on the "build/test" of the action; or try to create the correct event (not easy) to focus on the condition of the action, meaning validating/tweaking that the action is run under correct circumstances.

This is just down to bad vs good design. I see so many developers blindly writing code until it stops exploding and then fainting when they realise their code requires too much work to run in a unit test or work nicely with debugging.

Just like any good software design, you need to design your code with internal and external boundary abstractions so they can be easily wrapped in either case.

[airtonix]

lastly, if some of the actions you're using in your workflows absolutely have no local correltion:

• commenting on issue tickets or prs
• uploading files to a release
• pushing to remote

or if you have a workflow split into jobs and latter jobs depend on prior jobs which themselves have no local correlation, then:

This is two jobs, PrTitle and LintAndTest.

• PrTitle runs in local and github, but it's singular step only runs on github.
• LintAndTest runs in local and github, but doesn't require outputs from the PrTItle job

jobs:

  PrTitle:
    runs-on: ubuntu-latest
    permissions:
      statuses: write
    
      # if not using nekox/act and the user is airtonix, allow the action to run
      
    steps:
      - uses: aslafy-z/conventional-pr-title-action@v3
        if: ${{ !github.event.act }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  LintAndTest:

    runs-on: ubuntu-latest

    # don't bother running if the PR title is invalid
    needs: [PrTitle]

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

but what about when you have jobs that want output from prior jobs?

  Release:
    runs-on: ubuntu-20.04

    outputs:
      release_created: ${{ steps.release.outputs.release_created }}
      releases_created: ${{ steps.release.outputs.releases_created }}
      tag_name: ${{ steps.release.outputs.tag_name }} # e.g. v1.0.0
      version: ${{ steps.release.outputs.version }} # e.g. 1.0.0
      json: ${{ toJSON(steps.release.outputs) }}

    steps:
      - name: CreateOrUpdateRelease
        uses: google-github-actions/release-please-action@v3
        if: !github.event.act
        id: release-please
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          command: manifest
          release-type: go
          extra-files: |
            meta/package.go
      
      # this exists so we can faceroll this workflow locally with nekos/act
      - name: ReleasePleaseOrActInterop
        id: release
        run: |
          if [ "${{!github.event.act}}" == "false" ]; then
            echo "release_created=true" >> $GITHUB_OUTPUT
            echo "releases_created=true" >> $GITHUB_OUTPUT
            echo "tag_name=snapshot" >> $GITHUB_OUTPUT
            echo "version=snaphot" >> $GITHUB_OUTPUT
          else
            echo "release_created=${{ steps.release-please.outputs.release_created }}" >> $GITHUB_OUTPUT
            echo "releases_created=${{ steps.release-please.outputs.releases_created }}" >> $GITHUB_OUTPUT
            echo "tag_name=${{ steps.release-please.outputs.tag_name }}" >> $GITHUB_OUTPUT
            echo "version=${{ steps.release-please.outputs.version }}" >> $GITHUB_OUTPUT
          fi

  PrTitle:

    runs-on: ubuntu-20.04
    
    permissions:
      statuses: write

    steps:
      - uses: aslafy-z/conventional-pr-title-action@v3
        if: !github.event.act
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  Preview:
    if: !needs.Release.outputs.releases_created

    runs-on: ubuntu-20.04
    needs: [Release]

    steps:

      ...

So with this approach you're just left with the problem we all deal with:

• how to get a 1:1 accurate github runner container.

🤷🏻

the gh runner you use on github has so.much.stuff.installed. 🤯 (i'm currently stumped on how to accurately and easily simulate using nix or devbox locally for example)

[dimaqq]

That's true 🙇🏻
Feel free to close this issue as it doesn't feel actionable.