Permission error on GITHUB_OUTPUT Still present

[gthomson31]

Hi there

We have just tried to re-run the stale-repos action since the recent changes and have found the GITHUB_OUTPUT error is still present.

This issue was previously raised in #98

name: Stale Repositories Report Testing

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  stale-repos:
    name: Stale repository report
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run stale_repos tool
        uses: github/stale-repos@v1
        env:
          GH_TOKEN: ${{ secrets.GH_STALE_REPO_KEY }}
          ORGANIZATION: <ORG_NAME>
          INACTIVE_DAYS: 365

Example of the error

Found 65 stale repos in <ORG_NAME>
Traceback (most recent call last):
  File "/action/workspace/stale_repos.py", line 300, in <module>
    main()
  File "/action/workspace/stale_repos.py", line 57, in main
    output_to_json(inactive_repos)
  File "/action/workspace/stale_repos.py", line 244, in output_to_json
    with open(os.environ["GITHUB_OUTPUT"], "a") as file_handle:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: '/github/file_commands/set_output_f12c6469-3d43-4461-970d-03daabda9118'

[gthomson31]

@samuel-bland Adding for visibility

[jmeridth]

@gthomson31 confirmed this is still happening. I believe it is because we will never have permissions to write to $GITHUB_OUTPUT as a file. We can echo to it. I'm going to try that and see what happens. @zkoppert you may have more insight into $GITHUB_OUTPUT permissions.

[zkoppert]

☝ Agree with you that we should use the documented path of echoing to it.

[jmeridth]

@zkoppert my confusion is now related to this was possibly working in v1.10.0 (comment). Tested this is failing for me in v1.10.0 also when stale repos are detected. I may be missing something.

@gthomson31 could you please change your stale-repos actions to use:

uses: github/stale-repos@v1.10.0

again and see if it worked when stale-repos were detected? If not stale repos are detected no write occurs. If yours detects stale repos and the write succeeds we need to figure out the difference.

Thank you.

[jmeridth]

I'm working on this

[jmeridth]

Well that's very noisy. Sorry 🙇 Trying to shorten my dev cycle with live GitHub Action testing.

TLDR

My suggestion: rollback the changes in the Dockerfile where we specify a non-root user.

Details/Update:

So it seems we're in a losing battle by setting a non-root user in the Dockerfile.

And the GitHub docs state, we will be if we keep the non-root user.

Without root we will never have write access to $GITHUB_OUTPUT environment variable.  That environment variable is a file path (example: $GITHUB_OUTPUT = /home/runner/work/_temp/_runner_file_commands/set_output_76785449-caa5-4203-9a7e-2b774d621734 from one of my manual test runs)

/cc @zkoppert I'm going to put up a PR to go back to root user

[gthomson31]

Sorry just seen the github/stale-repos@v1.10.0 comment had tried on this also but faced the same issue

[jmeridth]

@gthomson31 thank you for confirming.

[jmeridth]

@gthomson31 please try out https://github.com/github/stale-repos/releases/tag/v1.11.2 and confirm this is fixed.

[jmeridth]

@gthomson31 I've tested and it is working for me again. I await your feedback. Cheers.

[gthomson31]

perfect - have just tested and working again now