Warning: pre execution is not supported for local action from './'

[zijchen]

I am one of the contributors for Azure/sql-action, and we have a workflow defined here that uses ./ to run our action and test some functionalities. I followed this guide to add a pre script for some setup code, like this:

runs:
  using: 'node12'
  pre: 'lib/setup.js'
  main: 'lib/main.js'

But in our workflow, it seems like that is ignored

Warning: pre execution is not supported for local action from './'

Is there a way to execute the pre script even for using ./?

A workaround would be to move the pre script into our main function, but we'd like to keep the setup code separate if possible.

[ncalteen]

Hello!

Apologies for the delay in responding to this issue. Currently, referencing the action locally will not let the pre step run. However, as a workaround, you can reference the local action by specifying the repository and path. For example, if your repository contains an action that looks like the following (index.js is the main script and setup.js is the pre script):

my-action
├── action.yml
├── index.js
├── package-lock.json
├── package.json
└── setup.js

You could reference the action in a workflow file like this:

jobs:
  run:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - uses: <owner>/<repo>/my-action@main

This should let pre script run as expected!

[LecrisUT]

I don't think that is equivalent, e.g. how can we make the github actions testable, especially for forks.

[nwalters512]

This workaround makes it impossible to test changes to an action in the repo in which it's developed, which I imagine is a very common use case for folks who are writing and referencing local actions. It'd work if one could write - uses: <owner>/<repo>/my-action@${{ github.sha }}, but that's not allowable.

Can someone from GitHub explain why pre: and friends aren't supported for local actions?

[ncalteen]

I did some checking internally to see why pre is not supported for local actions. The reason is because the action itself is downloaded and run after the job starts and any pre steps have run. On the other hand, post does work when referencing local actions.

As far as testing the action, you should be able to reference either your fork repo or branch name without issue:

- uses: <owner>/<fork-repo>@main
- uses: <owner>/<action-repo>@<feature-branch>

Are there specific errors you're running into when testing actions in a fork or branch? I'd be happy to dig into it if you have a reproducible example

[ncalteen]

Closing due to lack of activity. If you'd like to revisit this please open a new issue and provide any additional details that may be useful :)

[LecrisUT]

There is no activity because the request is clear. We need it for relative path. That's the form that works for gh actions to allow PRs, otherwise whenever a new PR is made, they need to point the unit tests to their fork, run the tests and point them back to the original repo before merging

[ncalteen]

Apologies! I misunderstood the request :/

I was able to find more info here. In particular:

Action referenced from local repository (./my-action) won't get pre setup correctly since the repository haven't checked-out during job initialization. We can't use GitHub api to download the repository since there is about a 3 minute delay between git push and the new commit available to download using GitHub api.

As far as current workarounds, yes you can fork the action repo, update the workflow to reference the forked repo name, and then update to the original repo name before submitting the PR.

Another option would be to convert to a composite action and move the pre/post steps into the "actual" workflow steps. E.g. instead of this:

runs:
  using: 'node12'
  pre: 'lib/setup.js'
  main: 'lib/main.js'

1. Convert the pre step to it's own action

   name: Setup Pre Action
   description: Setup Pre Action
   
   runs:
     using: node20
     main: ../lib/pre.js

2. Convert the main step to a separate action

   name: Main Action
   description: Main Action
   
   runs:
     using: node20
     main: ../lib/index.js

3. Call both actions in a composite

   name: Composite Action
   description: A composite action for demo purposes
   
   runs:
     using: composite
     steps:
       # This was previously a `pre` step in a Node.js action
       - name: Setup
         uses: ./setup-action
   
       # This was previously a `main` step in a Node.js action
       - name: Main
         uses: ./main-action

I created a trivial reproduction here if that helps. The benefit there is you shouldn't need to rename anything when forking and making updates.

[LecrisUT]

We can't use GitHub api to download the repository since there is about a 3 minute delay between git push and the new commit available to download using GitHub api.

Sorry, but this sounds luke bs on their side. Why can't the pre be delayed for after git checkout, and why would the delay not have a similar effect on the repo reference approach?

Another option would be to convert to a composite action and move the pre/post steps into the "actual" workflow steps

That is the approach I've converged to, but I don't like it because it wraps all of the stdout to composite-like output.

[ca-scribner]

Yeah I don't understand this one either. So the idea is that, if you want a native Github Action that uses pre, you can't have CI testing that action in your repository? Now I distrust anything that uses pre...

[jsoref]

So... I looked a bit...

@zijchen I filed github/docs#34029 to address the fact that the documentation didn't warn you about the problems you'd encounter (it's heartening to see people reading documentation).

---

As an example of why someone would add a pre in the first place...

Azure/login#384 added a pre to support clearing credentials

If you had uses: azure/login@... twice and they didn't use pre (but just included it in the main flow unconditionally), the second login would be liable to wipe out the first login, which obviously isn't ideal.

Note that this code/behavior actually lives in the runner: https://github.com/actions/runner/blob/2a7f327d93fb79326c974f4858ce62c3b81c580a/src/Runner.Worker/ActionRunner.cs#L108 and thus discussion doesn't really belong here.

I'm here because some random local action in microsoft/playwright uses azure/login and triggers this same warning.

In order to make things easier for me (as I'm liable to trip on this elsewhere, and in fact, I'm pretty sure I have in the past), I've filed: actions/runner#3397

If people are unhappy with the behavior or want different behavior, actions/runner is the repository to poke.

[jsoref]

@ca-scribner: I'm with you. In general, anyone using pre in an action with main is probably doing something that will not work well under various circumstances, and encouraging them to restructure their code into multiple actions would help the github ecosystem.