Permissions of translations after download are bad

[Bertg]

Describe the bug

I was trying to set up a new way of building our app with the latest fetched translation from Crowdin.

I added the following action:

     - name: ⤵️ Download translation from Crowdin
         uses: crowdin/github-action@v1
         with:
           upload_sources: false
           upload_translations: false
           download_translations: true
           create_pull_request: false
           push_translations: false
         env:
           CROWDIN_PERSONAL_TOKEN: ${{ secrets.CROWDIN_TOKEN }}

Very reasonable, I would say (although it is weird, that creating a PR is the default, instead of opting in.

However, after this step my build failed with:

$ lingui extract && lingui compile
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: EACCES: permission denied, open 'src/locales/en-GB/messages.po'] {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: 'src/locales/en-GB/messages.po'
}

That was unexpected. After adding some more debugging I got to see the file permissions created:

app/src/locales/nl:
total 464K
565681 4.0K drwxr-xr-x 12 runner docker 4.0K May 31 11:01 ..
565689 4.0K drwxr-xr-x  2 runner docker 4.0K May 31 11:04 .
545200 448K -rw-r--r--  1 root   root   448K May 31 11:04 messages.po 
545199 8.0K -rw-r--r--  1 runner docker 5.5K May 31 11:01 countries.json

The .po file is created by Crowdin, the countries.json is from the repo. As we can see the .po file is now belonging to root (not the current user, "runner") and because of that they are no longer writeable explaining the issue above.

To Reproduce

Steps to reproduce the behaviour:

1. Download translations files with GitHub action
2. Try to open these files for writing

Expected behavior

Downloaded files shoudl have sane default permissions and ownership

[Bertg]

For other people encountering this, my work around is to add the following line after the action has run:

      - name: 🧱Fix permission situation Crowdin created
        run: |
          sudo chmod -R 666 app/src/locales/**/*.po

[andrii-bodnar]

@Bertg do you have any ideas on how to implement this on the action side? The user's files might have different permissions and we'd like to avoid adding a new option to the action configuration. Also, I don't recall similar problems with permissions so it might be something more specific to your setup. Thank you!

[Bertg]

@andrii-bodnar Honestly I have no idea here. We have a very plain setup. We just run as runs-on: ubuntu-latest and use uses: actions/checkout@v4 to check out our source code. We have no special permissions.

• In this setup when I run touch some_file in a bash script, my files are created with runner docker permissions. (both before and after running the crowdin action). I think the action should make new files using the same permissions the default bash scripts would.
• The files were initially runner docker and after the action is run they are root root. As a bare minimum the action could try to keep the permissions the same if it is going to overwrite existing files.

If I were to guess, this may be part of the Docker setup for this action? Maybe something can be changed there?

[andrii-bodnar]

I just found a similar discussion in the past - #181 (comment)

It looks like having a separate step to customize the permission is fair in this case. For most Action users, the current behavior seems fine

[Bertg]

@andrii-bodnar This seems to be a common issue among docker based actions. I have found some resources that could help alleviate this, without - I assume - major changes:

• Docker specific, not GitHub actions: https://vocon-it.com/2020/03/15/avoid-docker-created-files-with-wrong-permissions-maven-example/
• Worker/action specific: Permission denied when "Deleting the contents of" actions/checkout#211
• A fix on the unity GitHub actions: https://github.com/game-ci/unity-builder/pull/141/files

I still think this is worthy of fixing, as more people will keep encountering this. It's just good developer experience :)

[erkannt]

We were just bitten by this. It is hard to debug GH Actions so saner defaults would have been nice.