You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation does not mention anything about my problem
There are no open or closed issues that are related to my problem
Description
Hi 👋
The recently released version 5.6.0 broke our CI because the format of the metadata GHA output changed. I understand that this is probably caused by dependencies of this action, but I was not sure where else to open the issue --- happy to be redirected elsewhere.
Concretely, one of our steps started to fail since we've been parsing the metadata output and we were passing it via an environment variable like this:
- name: Set output variables
run: |
.github/workflows/extract-image-names.sh | tee -a "${GITHUB_OUTPUT}" | awk -F'=' '{print $2}' | jq
env:
BAKE_METADATA: ${{ steps.build-upload.outputs.metadata }}
Because of the size, we started to hit this error:
Error: An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/aiidalab-docker-stack/aiidalab-docker-stack'. Argument list too long
We've been able to workaround this by saving the metadata output into a file first like this
Nevertheless, even with this workaround, it might be nice to try to prune the metadata output a bit to make it a bit more readable in the GHA logs. Specifically, there is now a section {"buildx.build.provenance": {"invocation": {...}} that is huge for multilevel builds.
Here's the output from the base image, nothing out of the ordinary
- name: Build and upload to ghcr.ioid: build-upload uses: docker/[email protected]with:
push: true# Using provenance to disable default attestation so it will build only desired images:# https://github.com/orgs/community/discussions/45969provenance: falseset: | *.platform=${{ inputs.platforms }} *.output=type=registry,push-by-digest=true,name-canonical=true *.cache-to=type=gha,scope=${{ github.workflow }},mode=max *.cache-from=type=gha,scope=${{ github.workflow }}files: | docker-bake.hcl build.json .github/workflows/env.hcl
- name: Set output image namesid: bake_metadata# bake-action metadata output has gotten too big, so we first write it# to a file. See https://github.com/aiidalab/aiidalab-docker-stack/issues/491
- name: Set output variables run: | .github/workflows/extract-image-names.sh | tee -a "${GITHUB_OUTPUT}" | awk -F'=' '{print $2}' | jq env:
BAKE_METADATA: ${{ steps.build-upload.outputs.metadata }}
Workflow logs
No response
BuildKit logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered:
Contributing guidelines
I've found a bug, and:
Description
Hi 👋
The recently released version 5.6.0 broke our CI because the format of the
metadata
GHA output changed. I understand that this is probably caused by dependencies of this action, but I was not sure where else to open the issue --- happy to be redirected elsewhere.Concretely, one of our steps started to fail since we've been parsing the metadata output and we were passing it via an environment variable like this:
Because of the size, we started to hit this error:
We've been able to workaround this by saving the metadata output into a file first like this
Nevertheless, even with this workaround, it might be nice to try to prune the metadata output a bit to make it a bit more readable in the GHA logs. Specifically, there is now a section
{"buildx.build.provenance": {"invocation": {...}}
that is huge for multilevel builds.Here's the output from the base image, nothing out of the ordinary
Here's the second part from the image built on top of
base
image(I elided the full output)
It would be great if the
"input-metadata:0-base": "{\"containerimage.config\":
section was not there.Repository URL
https://github.com/aiidalab/aiidalab-docker-stack
Workflow run URL
https://github.com/aiidalab/aiidalab-docker-stack/actions/runs/10283635135/job/28465139810
YAML workflow
Workflow logs
No response
BuildKit logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: