fix: Since yesterday `Buildah` has been failing as seen below

[dperson]

When running the github-action (on my custom ublue build) I'm now getting the below failure, starting with yesterday's scheduled build:

Run blue-build/github-action@v1
Run actions/checkout@v4
Syncing repository: dperson/silver-ublue
Getting Git version info
Temporarily overriding HOME='/home/runner/work/_temp/02a0478c-20af-436e-8d2e-f6470bc12876' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /home/runner/work/silver-ublue/silver-ublue
Deleting the contents of '/home/runner/work/silver-ublue/silver-ublue'
Initializing the repository
Disabling automatic garbage collection
Setting up auth
Fetching the repository
Determining the checkout info
/usr/bin/git sparse-checkout disable
/usr/bin/git config --local --unset-all extensions.worktreeConfig
Checking out the ref
/usr/bin/git log -1 --format='%H'
'ac19d42787d1609f6dd18acc242d25a4d8b80ea5'
Run if [[ "false" == "true" ]]; then
Run podman run \
Trying to pull ghcr.io/blue-build/cli:v0.8-alpine...
Getting image source signatures
Copying blob sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
Copying blob sha256:a5d78f6d0188b41d8653aef603f25781dcb94d11c117242c1835fa31837f545e
Copying blob sha256:d25f557d7f31bf7acfac935859b5153da41d13c41f2b468d16f729a5b883634f
Copying blob sha256:c74c1c3b4ce91aa5043e919fe81feffa57027b1324b1631e9b10ed6d34514c94
Copying blob sha256:ef932fc9d23cc2b5b24e5e8ef883d1520461c3f470c62be0bcc0ab12901ff1d8
Copying blob sha256:464a1e232b3865b75c9c6f58a5c818128a56b1748f5b0f1e518a228f3349bb37
Copying blob sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
Copying blob sha256:e38b324506f167260fc72cbd34898d88478259ea365969f9d3dfc5cf2688abbf
Copying blob sha256:d25f557d7f31bf7acfac935859b5153da41d13c41f2b468d16f729a5b883634f
Copying blob sha256:464a1e232b3865b75c9c6f58a5c818128a56b1748f5b0f1e518a228f3349bb37
Copying blob sha256:ef932fc9d23cc2b5b24e5e8ef883d1520461c3f470c62be0bcc0ab12901ff1d8
Copying blob sha256:a5d78f6d0188b41d8653aef603f25781dcb94d11c117242c1835fa31837f545e
Copying blob sha256:c74c1c3b4ce91aa5043e919fe81feffa57027b1324b1631e9b10ed6d34514c94
Copying blob sha256:e38b324506f167260fc72cbd34898d88478259ea365969f9d3dfc5cf2688abbf
Copying config sha256:92ff032986a654429f52dd6cfc1359d9b772908017a3a57d888d8337da0ed57a
Writing manifest to image destination
Storing signatures
[01:09:59 DEBUG] => Cosign files match, continuing build
[01:09:59  INFO] => Attempting to login to the registry
[01:09:59  INFO] => Logging into the registry, ghcr.io
[01:09:59 ERROR] => Failed to login for buildah: time="2024-05-30T01:09:59Z" level=warning msg="Error loading default container config when searching for local runtime: lstat /run/user: no such file or directory"
time="2024-05-30T01:09:59Z" level=error msg="failed to setup From and Build flags: failed to get default container config: lstat /run/user: no such file or directory"

Error: Process completed with exit code 1.

Excerpt of the relevant action from the YAML:

jobs:
  bluebuild:
    name: Build Custom Image
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write
    strategy:
      fail-fast: false # stop GH from cancelling all matrix builds if one fails
      matrix:
        recipe: # !! Add your recipes here
          - recipe.yml
          #- recipe-beta.yml
    steps: # the build is fully handled by the reusable github action
      - name: Build Custom Image
        uses: blue-build/github-action@v1
        with:
          recipe: ${{ matrix.recipe }}
          cosign_private_key: ${{ secrets.SIGNING_SECRET }}
          registry_token: ${{ github.token }}
          pr_event_number: ${{ github.event.number }}
          squash: true

[dperson]

Note, no change was made to my repo from the previous successful build to it getting errors on the scheduled build. Thanks!

  schedule:
    - cron: "00 17 * * *" # build at 17:00 UTC every day
                          # (20 minutes after last ublue images start building)

[gmpinder]

Can confirm, my test build fails when using squash. No changes were made by us so this might have something to do with the repo we're using to install podman. This will require further investigation

[gmpinder]

Scratch that, changes were made around removing a hard requirement for providing credentials to allow the container runtimes to use credentials that were already set (https://github.com/blue-build/cli/pull/187). I'm pretty sure these changes wouldn't have caused this issue, but it won't hurt to start investigating there

[dperson]

Possible enhancement/feature request: ability to set CLI_VERSION_TAG to an arbitrary value (git hash) when calling the blue-build/github-action (instead of just the indirect use_unstable_api for v0.8 or main)? It would make testing if this change caused the issue easier...

Thanks for creating / maintaining such nice tools!

[gmpinder]

I think I see what the problem is. It seems to be related to the fact that the currently released version of the action is building inside of an alpine container. We have changes in main that will install a newer version of podman directly on the runner. The new method works fine. @xynydev I've got a PR to add the requested cli_version input. Can we get that reviewed and the action released soon? Squash builds will continue to be broken until we do.

[gmpinder]

Current released action with squash https://github.com/gmpinder/testos/actions/runs/9306358911/job/25623380967 (failing)

New PR action with squash on v0.8.10 CLI https://github.com/gmpinder/testos/actions/runs/9308915971/job/25623318577 (passing)

New PR action with squash on v0.8.9 CLI https://github.com/gmpinder/testos/actions/runs/9308897726/job/25623703999 (passing)

[dperson]

@gmpinder 2 questions:

1. I tried to build with main (via use_unstable_cli: true) and it still failed to build, which doesn't sound like it was supposed to happen from your comments, or did I misunderstand?
2. Was the success because you used the new flag cli_version (from your PR) and grabbed the older one prior to the mentioned change?

Thanks!

[gmpinder]

@gmpinder 2 questions:

1. I tried to build with main (via use_unstable_cli: true) and it still failed to build, which doesn't sound like it was supposed to happen from your comments, or did I misunderstand?
2. Was the success because you used the new flag cli_version (from your PR) and grabbed the older one prior to the mentioned change?

Thanks!

The main branch of the action has a fix for this issue that hasn't been released yet. Changing the version of the CLI won't do anything for this particular issue. You can take a look at the difference between the latest tag and main to see the difference.

[dperson]

Whee... and it builds a lot faster too (15m 34s => 9m 34s). Thank you so much!