Local workflows fail for private repos #91

New Issue

Thanks for the quick fix to support local workflows! Unfortunately I run into another issue while using them on one of my private repos:

default(version:develop) received task 157 of job 116, be triggered by event: push
workflow prepared
evaluating expression 'success()'
expression 'success()' evaluated to 'true'
  ☁  git clone 'https://git.mug.lv/galen/images' # ref=84e639faa5405f0762a1ea1c73c691e482ce528a
  cloning https://git.mug.lv/galen/images to /home/runner/.cache/act/galen-images-.github-workflows-build.yaml@84e639faa5405f0762a1ea1c73c691e482ce528a
Unable to clone https://git.mug.lv/galen/images refs/heads/84e639faa5405f0762a1ea1c73c691e482ce528a: authentication required
authentication required

This happens in the Set up job step and nothing else runs. Based on the output from other workflows which don't use local workflows, I guess the GITEA_TOKEN environment variable isn't set until later in the workflow and probably needs to be set early for the first set of clones in case they are private.

Thanks for the quick fix to support local workflows! Unfortunately I run into another issue while using them on one of my private repos: ```bash default(version:develop) received task 157 of job 116, be triggered by event: push workflow prepared evaluating expression 'success()' expression 'success()' evaluated to 'true' ☁ git clone 'https://git.mug.lv/galen/images' # ref=84e639faa5405f0762a1ea1c73c691e482ce528a cloning https://git.mug.lv/galen/images to /home/runner/.cache/act/galen-images-.github-workflows-build.yaml@84e639faa5405f0762a1ea1c73c691e482ce528a Unable to clone https://git.mug.lv/galen/images refs/heads/84e639faa5405f0762a1ea1c73c691e482ce528a: authentication required authentication required ``` This happens in the `Set up job` step and nothing else runs. Based on the output from other workflows which don't use local workflows, I guess the `GITEA_TOKEN` environment variable isn't set until later in the workflow and probably needs to be set early for the first set of clones in case they are private.

Thanks for your report! I'll try to fix it.

I did some digging and it looks like it's a simple fix; the runner.Config struct has a Token field which isn't set here: https://gitea.com/gitea/act_runner/src/branch/main/runtime/task.go#L214.

The token is already fetched above so just setting:

	config := &runner.Config{
		Token: token,
		...
	}

seems to be enough to fix it!

Unfortunately I immediately ran into another problem: the inputs in the reusable workflow are unset. My workflow looks something like this:

on:
  workflow_call:
    inputs:
      package:
        type: string

jobs:
  build:
    steps:
      - run: |
          manifest="${{ inputs.package }}/manifest.yaml"

With a calling workflow like this:

on: push

jobs:
  build:
    uses: ./.github/workflows/build.yaml
    with:
      package: mypackage

The manifest variable resolves to /manifest.yaml instead of mypackage/manifest.yaml.

It looks like that runner.Config struct also has an inputs field which might fix this, but I'm not sure where the value would come from.

I did some digging and it looks like it's a simple fix; the `runner.Config` struct has a `Token` field which isn't set here: https://gitea.com/gitea/act_runner/src/branch/main/runtime/task.go#L214. The token is already fetched above so just setting: ```golang config := &runner.Config{ Token: token, ... } ``` seems to be enough to fix it! Unfortunately I immediately ran into another problem: the `inputs` in the reusable workflow are unset. My workflow looks something like this: ```yaml on: workflow_call: inputs: package: type: string jobs: build: steps: - run: | manifest="${{ inputs.package }}/manifest.yaml" ``` With a calling workflow like this: ```yaml on: push jobs: build: uses: ./.github/workflows/build.yaml with: package: mypackage ``` The `manifest` variable resolves to `/manifest.yaml` instead of `mypackage/manifest.yaml`. It looks like that `runner.Config` struct also has an `inputs` field which might fix this, but I'm not sure where the value would come from.

I did some digging and it looks like it's a simple fix

I think this is a workaround to reuse a workflow from the same repository. But when we try to reuse a workflow from another private repository, I guess it won't work because the token cannot be authenticated by other repositories.

the inputs in the reusable workflow are unset

This is another bug. I'll do more tests to check.

> I did some digging and it looks like it's a simple fix I think this is a workaround to reuse a workflow from the same repository. But when we try to reuse a workflow from another private repository, I guess it won't work because the token cannot be authenticated by other repositories. > the `inputs` in the reusable workflow are unset This is another bug. I'll do more tests to check.

Good point, although I think this would then be consistent with Github's behavior when it comes to tokens (as far as I know the token that's automatically generated is scoped only to the current repo). Maybe it should first look for a user-managed secret called GITEA_TOKEN and fallback to the default token if it doesn't exist?