`tdnf` not working in GitHub Actions

[jiasli]

`tdnf` not working in GitHub Actions

[jiasli]

I tested with the below task and tdnf works as expected:

    - name: Azure CLI script
      uses: azure/cli@v2
      with:
        azcliversion: 2.64.0
        inlineScript: |
          set -x
          env
          env | base64
          tdnf install -y zip
          zip --help
          tdnf install -y jq
          jq --help

Output:

+ tdnf install -y zip
Loaded plugin: tdnfrepogpgcheck

Refreshing metadata for: 'CBL-Mariner Official Extras 2.0 x86_64'

Refreshing metadata for: 'CBL-Mariner Official Base 2.0 x86_64'

Refreshing metadata for: 'CBL-Mariner Official Microsoft 2.0 x86_64'


Installing:
zip              x86_64       3.0-5.cm2        mariner-official-base 546.32k   282.71k

Total installed size: 546.32k
Total download size: 282.71k



Testing transaction

Running transaction

Installing/Updating: zip-3.0-5.cm2.x86_64

...

+ tdnf install -y jq
Loaded plugin: tdnfrepogpgcheck


Installing:
oniguruma        x86_64       6.9.7.1-2.cm2    mariner-official-base 595.97k   198.73k
jq               x86_64       1.6-2.cm2        mariner-official-base 405.57k   196.06k

Total installed size: 1001.53k
Total download size: 394.79k





Testing transaction

Running transaction

Installing/Updating: oniguruma-6.9.7.1-2.cm2.x86_64

Installing/Updating: jq-1.6-2.cm2.x86_64

The env var HOME points to /root.

@mr-sven, could you please share more information on your action and how to repro the error?

[mr-sven]

Running via Container does not work:

deploy:
    needs: build
    runs-on: [self-hosted, linux, docker]
    container: mcr.microsoft.com/azure-cli
    steps:
    - name: Cleanup build folder
      run: |
        tdnf install -y zip

In the end it will be a general issue if someone uses the Image on custom pipelines or whatever.
I recommend to set the environment variable GNUPGHOME to /root/.gnupg within the docker file, so tdnf will always work regardless what the HOME variable is.

[jiasli]

@mr-sven, thanks for the information. I am able to repro with GitHub-hosted runners too:

on: [push, workflow_dispatch]

name: AzureCLISample

permissions:
  id-token: write
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    container: mcr.microsoft.com/azure-cli
    steps:
    - name: Test tdnf
      run: |
        env
        tdnf install -y zip

Output:

Loaded plugin: tdnfrepogpgcheck
Refreshing metadata for: 'CBL-Mariner Official Extras 2.0 x86_64'
repo md signature check: No public key
Error: TDNFVerifySignature 2004
Plugin error: repogpgcheck plugin error: failed to verify signature

Error(2004) : Unknown error 404
Error: Failed to synchronize cache for repo 'CBL-Mariner Official Extras 2.0 x86_[64](https://github.com/jiasli/github-action-test/actions/runs/10712257860/job/29702352823#step:3:65)'
Disabling Repo: 'CBL-Mariner Official Extras 2.0 x86_64'
Refreshing metadata for: 'CBL-Mariner Official Microsoft 2.0 x86_64'
repo md signature check: No public key
Disabling Repo: 'CBL-Mariner Official Microsoft 2.0 x86_64'
Error: TDNFVerifySignature 2004
Refreshing metadata for: 'CBL-Mariner Official Base 2.0 x86_64'
Plugin error: repogpgcheck plugin error: failed to verify signature

Error(2004) : Unknown error 404
Error: Failed to synchronize cache for repo 'CBL-Mariner Official Microsoft 2.0 x86_64'
repo md signature check: No public key
Error: TDNFVerifySignature 2004
Plugin error: repogpgcheck plugin error: failed to verify signature

Error(2004) : Unknown error 404
Error: Failed to synchronize cache for repo 'CBL-Mariner Official Base 2.0 x86_64'
Disabling Repo: 'CBL-Mariner Official Base 2.0 x86_64'
zip package not found or not installed
Error(1011) : No matching packages

env shows:

HOME=/github/home

This is different from what is in azure/cli@v2 action:

HOME=/root

@MoChilia, do you have any insights on this inconsistency?

[MoChilia]

When running GitHub Action jobs in a container, the command docker create ... -e "HOME=/github/home" is executed, which sets HOME to /github/home. However, the azure/cli action does not overwrite the environment HOME for the image.

I have tested this using the azure/cli action and on my local machine. In both cases, the .gnupg folder appears in the root directory. However, when directly running a container in a job in GitHub Actions, the .gnupg folder does not appear in the root directory. /github/home is empty.

@mr-sven, since using the azure/cli action is the more recommended approach to run Azure CLI commands in GitHub Actions, could you please run your CLI scripts using azure/cli instead of running jobs directly in a container? It actually does the same thing as the azure/cli action. Here is the sample for running tdnf in azure/cli action.

    - name: Azure CLI script
      uses: azure/cli@v2
      with:
        azcliversion: 2.64.0
        inlineScript: |
          tdnf install -y zip
          <Your Azure CLI commands here>

[mr-sven]

That will work.
The use of azure/cli as task forces me to put all steps into a single task. I don't know if this is the right approach. Executing a single command or a small command list is ok, but using complex pipelines spread over multiple steps will not work.

    steps:
      - name: Azure CLI zip install
        uses: azure/cli@v2
        with:
            azcliversion: 2.64.0
            inlineScript: |
              tdnf install -y zip

      - name: Azure cli zip use
        uses: azure/cli@v2
        with:
            azcliversion: 2.64.0
            inlineScript: |
              zip -r publish.zip .

### Azure CLI zip install
Run azure/cli@v2
  with:
    azcliversion: 2.64.0
    inlineScript: tdnf install -y zip
  
Starting script execution via docker image mcr.microsoft.com/azure-cli:2.64.0
Loaded plugin: tdnfrepogpgcheck
Refreshing metadata for: 'CBL-Mariner Official Base 2.0 x86_64'
Refreshing metadata for: 'CBL-Mariner Official Extras 2.0 x86_64'
Refreshing metadata for: 'CBL-Mariner Official Microsoft 2.0 x86_64'
Installing:
zip              x86_64       3.0-5.cm2        mariner-official-base 546.32k   282.71k
Total installed size: 546.32k
Total download size: 282.71k
Testing transaction
Running transaction
Installing/Updating: zip-3.0-5.cm2.x86_64
az script ran successfully.
cleaning up container...
MICROSOFT_AZURE_CLI_1725525696995_CONTAINER

### Azure cli zip use
Run azure/cli@v2
  with:
    azcliversion: 2.64.0
    inlineScript: zip -r publish.zip .
Starting script execution via docker image mcr.microsoft.com/azure-cli:2.64.0
/home/actions-runner/runner-2/_work/_temp/AZ_CLI_GITHUB_ACTION_1725525734948.sh: line 4: zip: command not found
Error: Error: az cli script failed.
cleaning up container...
MICROSOFT_AZURE_CLI_1725525734823_CONTAINER
Error: az cli script failed.

By using this I'm forced to combine clear separated and visible steps into a single shell script.

[MoChilia]

@mr-sven, yes, you’ll need to put all steps into a single task when using azure/cli action. But I am afraid there is no better workaround at the moment. This issue of "$HOME overridden for containers" has been reported since 2020, and no good solution has been found yet. See actions/runner#863.

[mr-sven]

As I mentioned above, if you set the env variable GNUPGHOME to /root/.gnupg within the Dockerfile it solves the issue. It also save the image usage outside of github wherever somebody is used to change the HOME variable.

[MoChilia]

@mr-sven, you're right. Setting GNUPGHOME to /root/.gnupg worked for me.

To summarize, here are two solutions for this issue:

• Option 1: Using azure/cli action

     - name: Azure CLI script
       uses: azure/cli@v2
       with:
         azcliversion: 2.64.0
         inlineScript: |
           tdnf install -y zip
           <Your Azure CLI commands here>

• Option 2: Set GNUPGHOME to /root/.gnupg

  jobs:
    deploy:
       runs-on: ubuntu-latest
       container: 
         image: mcr.microsoft.com/azure-cli
         env:
            GNUPGHOME: /root/.gnupg
       steps:
       - name: Cleanup build folder
         run: |
            tdnf install -y zip
            <Your Azure CLI commands here>

Closing this issue for now, as it caused by GitHub Actions and solutions are available.