Action step with git authentication fails inside workflow_call when needs is set #13417

Open
opened 2025-11-02 10:41:45 -06:00 by GiteaMirror · 3 comments
Owner

Originally created by @javiertury on GitHub (Aug 22, 2024).

Description

Doing a git checkout (actions/checkout@v4) inside a workflow_call that needs another job raises an authentication error.

It can be reproduced using the following nested workflow.

Workflow to reproduce the error
# .gitea/workflows/main.yaml
name: test
run-name: test

on:
  workflow_dispatch:
  push:
    branches:
      - main


jobs:
  foo:
    runs-on: ubuntu-latest
    steps:
      -
        name: Foo
        run: |
          echo 'foo: ${{ inputs.foo }}'

  # Works fine, even if it has a dependency
  outer_needy_checkout:
    runs-on: ubuntu-latest
    needs: [foo]
    steps:
      -
        name: Outer needy checkout
        uses: https://github.com/actions/checkout@v4

  nested_checkout:
    runs-on: ubuntu-latest
    uses: ./.gitea/workflows/nested-checkout.yaml
    with:
      foo: bar
    secrets: inherit

  nested_needy_checkout:
    runs-on: ubuntu-latest
    uses: ./.gitea/workflows/nested-checkout.yaml
    needs: [foo]
    with:
      foo: bar
    secrets: inherit
# .git/workflows/nested-checkout.yaml

name: nested git checkout
run-name: nested git checkout
on:
  workflow_call:
    inputs:
      foo:
        type: string
        required: false

jobs:
  foo:
    runs-on: ubuntu-latest
    steps:
      -
        name: Foo
        run: |
          echo 'foo: ${{ inputs.foo }}'
      # This checkout works fine too, even though we are in a workflow_call
      -
        name: Nested checkout
        uses: https://github.com/actions/checkout@v4

  # fatal: could not read Username for '<repo>': terminal prompts disabled
  inner_needy_checkout:
    runs-on: ubuntu-latest
    needs: [foo]
    steps:
      -
        name: Nested needy checkout
        uses: https://github.com/actions/checkout@v4

The step Nested needy checkout fails with

fatal: could not read Username for '<repo>': terminal prompts disabled

Bear in mind that due to bugs https://github.com/go-gitea/gitea/issues/26736 and https://github.com/go-gitea/gitea/issues/26187, the UI marks the job as a sucess, but reading the logs in details reveals the error.

Gitea Version

1.22.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

image

Git Version

No response

Operating System

No response

How are you running Gitea?

I'm using the official gitea helm chart on k3s

Database

SQLite

Originally created by @javiertury on GitHub (Aug 22, 2024). ### Description Doing a git checkout (`actions/checkout@v4`) inside a `workflow_call` that `needs` another job raises an authentication error. It can be reproduced using the following nested workflow. <details> <summary>Workflow to reproduce the error</summary> ```yaml # .gitea/workflows/main.yaml name: test run-name: test on: workflow_dispatch: push: branches: - main jobs: foo: runs-on: ubuntu-latest steps: - name: Foo run: | echo 'foo: ${{ inputs.foo }}' # Works fine, even if it has a dependency outer_needy_checkout: runs-on: ubuntu-latest needs: [foo] steps: - name: Outer needy checkout uses: https://github.com/actions/checkout@v4 nested_checkout: runs-on: ubuntu-latest uses: ./.gitea/workflows/nested-checkout.yaml with: foo: bar secrets: inherit nested_needy_checkout: runs-on: ubuntu-latest uses: ./.gitea/workflows/nested-checkout.yaml needs: [foo] with: foo: bar secrets: inherit ``` ```yaml # .git/workflows/nested-checkout.yaml name: nested git checkout run-name: nested git checkout on: workflow_call: inputs: foo: type: string required: false jobs: foo: runs-on: ubuntu-latest steps: - name: Foo run: | echo 'foo: ${{ inputs.foo }}' # This checkout works fine too, even though we are in a workflow_call - name: Nested checkout uses: https://github.com/actions/checkout@v4 # fatal: could not read Username for '<repo>': terminal prompts disabled inner_needy_checkout: runs-on: ubuntu-latest needs: [foo] steps: - name: Nested needy checkout uses: https://github.com/actions/checkout@v4 ``` </details> The step `Nested needy checkout` fails with ``` fatal: could not read Username for '<repo>': terminal prompts disabled ``` Bear in mind that due to bugs https://github.com/go-gitea/gitea/issues/26736 and https://github.com/go-gitea/gitea/issues/26187, the UI marks the job as a sucess, but reading the logs in details reveals the error. ### Gitea Version 1.22.1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![image](https://github.com/user-attachments/assets/cad8b4c8-5a9a-4de8-a716-eae025a74a28) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? I'm using the official gitea helm chart on k3s ### Database SQLite
GiteaMirror added the topic/gitea-actionstype/bug labels 2025-11-02 10:41:45 -06:00
Author
Owner

@Zettat123 commented on GitHub (Sep 11, 2024):

This bug is not related to needs. Actually, this bug can be reproduced without needs, but not stably. The reason should be that Gitea does not correctly handle reusable workflows with multiple jobs.

@Zettat123 commented on GitHub (Sep 11, 2024): This bug is not related to `needs`. Actually, this bug can be reproduced without `needs`, but not stably. The reason should be that Gitea does not correctly handle reusable workflows with multiple jobs.
Author
Owner

@lunny commented on GitHub (Sep 24, 2024):

This should be fixed by https://gitea.com/gitea/act/pulls/116

@lunny commented on GitHub (Sep 24, 2024): This should be fixed by https://gitea.com/gitea/act/pulls/116
Author
Owner

@WereCatf commented on GitHub (Nov 15, 2024):

This should be fixed by https://gitea.com/gitea/act/pulls/116

Um, no, it's not. I just ran into this issue myself and authentication still fails with the "could not read Username for" message. Given that the issue is not fixed, I don't understand why this was closed.

@WereCatf commented on GitHub (Nov 15, 2024): > This should be fixed by https://gitea.com/gitea/act/pulls/116 Um, no, it's not. I just ran into this issue myself and authentication still fails with the "could not read Username for" message. Given that the issue is not fixed, I don't understand why this was closed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#13417