chainguard-dev / actions Goto Github PK

Sometimes it's desireable to not have to specify the exact version of the, say knative version. Some reasons are:

• The components don't all have that specific version
• you really don't care which minor version it is

In #153 I added a latest that will pull the latest version for each, but again, it might be nice to go back to an older version like v1.6.x.

2024-04-10T11:55:40.7937799Z ##[group]Run thollander/actions-comment-pull-request@fabd468d3a1a0b97feee5f6b9e499eab0dd903f6
2024-04-10T11:55:40.7938384Z with:
2024-04-10T11:55:40.7938595Z   filePath: diff.log
2024-04-10T11:55:40.7939344Z   GITHUB_TOKEN: ***
2024-04-10T11:55:40.7939599Z   mode: upsert
2024-04-10T11:55:40.7939838Z   create_if_not_exists: true
2024-04-10T11:55:40.7940119Z ##[endgroup]
2024-04-10T11:55:41.0317790Z ##[error]Resource not accessible by integration
2024-04-10T11:55:41.0405868Z ##[group]Run actions/upload-artifact@5d5d22a31266ced268874388b861e4b58bb5c2f3
2024-04-10T11:55:41.0406471Z with:
2024-04-10T11:55:41.0406723Z   path: ./packages/x86_64
./packages.log

As mentioned in annotations at https://github.com/wolfi-dev/os/actions/runs/8630712801

The idea here is to make the networking layer a bit more fungible. We want to switch to using net-istio in mesh mode, but I can imagine there may be instances of folks using this downstream where they may be reaching in and pulling out the kourier LB IP address.

cc @tcnghia

• boilerplate/action.yaml: # TODO(mattmoor): Cut a release of boilerplate-check we can use instead.
• setup-kind/action.yaml: required: true # TODO(mattmoor): Make this optional
• setup-melange/action.yaml: # TODO: the bubblewrap package available from "apt install"

I noticed this in some runs that had early failures, there seems to be a loop polling grafana, which doesn't exist.

cc @cpanato

I found the apko-build action and was wondering, if there was a complimentary action to publish/push the image to e.g. the Github registry? As far as I understood the result of the apko-build action is only a local file?

Kind Regards,
Johannes

I found in the logs of knative activator deployment 2023/08/09 16:04:49 Failed to get k8s version kubernetes version "1.24.15" is not compatible, need at least "1.25.0-0" (this can be overridden with the env var "KUBERNETES_MIN_VERSION")

You can find one occurrence of this issue here: https://github.com/chainguard-dev/actions/actions/runs/5811350964/job/15754381602?pr=292#step:6:431

This seems like a potentially useful piece of information, especially for debugging issues related to removing CRDs that use finalizers.

We should spin up 1.26 clusters in e2e

https://github.com/chainguard-dev/actions/blob/31bf940ed7cbea2978229012cce040849c94fd8d/setup-chainguard-terraform/action.yaml#L66C16-L66C60

registry.terraform.io only has chainguard-dev.

This downloads the SBOM attestation and massages it into a simple list of package@versions for an image that has them.

function packages() {
  cosign download attestation \
    $(crane digest --full-ref --platform=${2:-linux/amd64} $1) \
    --predicate-type="https://spdx.dev/Document" | \
      jq -r '.payload' | base64 -d | \
      jq -r '.predicate.packages[] | ("\(.name) \(.versionInfo)")' | \
      grep -v sha256: | sort | uniq
}

example:

$ packages cgr.dev/chainguard/busybox:latest-glibc
busybox 1.36.1-r0
ca-certificates-bundle 20230506-r0
glibc 2.37-r6
glibc-locale-posix 2.37-r7
ld-linux 2.37-r7
wolfi-baselayout 20230201-r3

It could be cool for digesta-bot to include any package diffs in the description of the PR it opens with changes.

$ old=cgr.dev/chainguard/busybox@sha256:dda91f4fc322187003a093a60a7322604462cbf314d8c0ebfc3d4d075c8d7efe
$ new=cgr.dev/chainguard/busybox:latest-glibc
$ diff <(packages $old) <(packages $new)
1c1
< busybox 1.36.0-r5
---
> busybox 1.36.1-r0
3d2
< github.com/chainguard-images/images c8a42f1fed31ee9f5e5eb91e553817ca285c589b
5,7c4,6
< glibc-locale-posix 2.37-r6
< ld-linux 2.37-r6
< wolfi-baselayout 20230201-r0
---
> glibc-locale-posix 2.37-r7
> ld-linux 2.37-r7
> wolfi-baselayout 20230201-r3

Or even if not diffing, we could list the package versions of the new image(s), which can be useful.

Just like how container images should be referenced by digest, GitHub actions should be referenced by SHA and not tag. Dependabot can handle this pattern including keeping the tag used next to the SHA as a comment.

jobs:
  test:
    steps:
      - name: Checkout
        uses: actions/checkout@ac593985615ec2ede58e132d2e21d2b1cbd6127c # v3.3.0

Lots of helm charts have image: and tag: on separate lines. For example from SPIRE helm chart:

    registry: cgr.dev
    # -- The repository within the registry
    repository: chainguard/bash
    # -- Overrides the image tag
    tag: latest@....

Would be great if digesta bot handled this layout.

/cc @cpanato

presubmit-roundup
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: technote-space/workflow-conclusion-action@45ce8e0. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

As seen on https://github.com/chainguard-images/images/actions/runs/8631273464 please upgrade if possible

Using chainguard-dev/actions/melange-build@main without specifying sign-with-temporary-key results in the key being generated (overwritten) regardless of the conditional @ https://github.com/chainguard-dev/actions/blob/main/melange-build/action.yaml#L64.

    @vaikas @cpanato maybe we should beef up the `setup-kind` testing here to setup `sigstore/scaffolding`?  Then we should be able to detect this pretty quickly 🤞

Originally posted by @mattmoor in #173 (comment)

I'm working on a test that references the ghcr.io/wolfi-dev/apko image from within a bash-based test, and it'd be great if these were bumped by digestabot.

Not sure if this would break anything 🤔

cc @cpanato

Had an idea, not sure if it's a good one.

apko-build takes a path to a config file, but it could also take the actual contents of the config file:

- uses: chainguard-dev/actions/apko-build@main
  with:
    config: |
      contents:
        repositories:
          - https://dl-cdn.alpinelinux.org/alpine/edge/main
        packages:
          - alpine-base
      cmd: /bin/sh -l
      archs:
        - amd64

    tag: ghcr.io/chainguard-dev/apko-example:latest

Nested YAML strings are kinda 🤮, it won't nicely check that the inner YAML is valid until apko tries to run it. But it could be nice if you have a lot of configs in your repo that are only invoked by the GitHub action workflow.

Maybe config-contents vs config, and fail if both are specified. If neither are specified, still default to config: .apko.yaml.

WDYT? @kaniini

See: #35

Currently it goes like

wget --progress=dot:giga \
    https://github.com/spdx/tools-java/releases/download/v${{ inputs.spdx-tools-version }}/tools-java-${{ inputs.spdx-tools-version }}.zip

GHA images include GitHub CLI.
So we can improve the process.

mkdir -p "${{ runner.temp }}/spdx"
RELEASE_ASSET_URL="$(
    gh api /repos/spdx/tools-java/releases/${{ inputs.spdx-tools-release-id }} \
        --jq '."assets"[] | select(."name" | test("^tools-java-.+\\.zip$")) | ."browser_download_url"'
)"
wget --secure-protocol=TLSv1_3 --max-redirect=1 --retry-on-host-error --retry-connrefused --tries=3 \
    --no-verbose --output-document="${{ runner.temp }}/spdx/tools-java.zip" "${RELEASE_ASSET_URL}"

source

Here is how to list releases.

gh api /repos/spdx/tools-java/releases --jq '.[] | ."name" + ":" + (."id"|tostring)'

AFAIK, the registry address is changed from ghcr.io/distroless to cgr.dev/chainguard, but in this repository, images still use the old registry address.

/cc @cpanato @imjasonh

https://github.com/chainguard-dev/melange/actions/runs/8526927513

has many errors, and pages of error messages..... but lint works, and there are non red-herring issues identified in the end of the run.

I don't know if lint pipeline can be improved to be a "github checker" which does inline code comments on things it identifies.

And separately I don't understand the tar errors, possibly to do with restoring precached runs? which fails and are ignored? maybe turning off attempts to restore cache will make the build faster and have less errors.

We upload logs from e2e tests. But we also run matrix jobs. If we fail more than one e2e test, we get a single logs.tar.gz file. and ... I have no idea which run it is tied to. I assume it is the last one. Can we name the logs artifact with some of the test name?

We're looking to refer to digesta-bot in a blog post. Before this happens, I think we could do with some more docs to explain what it is and how it works.

https://github.com/chainguard-dev/actions/tree/main/digesta-bot

I'm proposing updating the setup-kind action to allow creating single node clusters (i.e. with no workers, only a single control-plane node).

Currently, the action requires at least one worker node, which means it isn't possible to create a single node kind cluster.

And, counter-intuitively, if a user specifies kind-worker-count: 0, they'll actually end up with two workers, as the loop at

$ for x in {1..0}; do echo "x"; done
x
x

So that should probably be fixed, even if you still want to require at least one worker node.

I am building a APK package, that is not (yet) included in Wolfi, in a Github Action. I am using both the setup-melange and melange-build-pkg actions.

After the package build, I would like to use that package in the apko-publish action to create an image using the local repository created by the previous step.

I have not found documentation on how to do that, unfortunately.

I got it working, so if someone wants to do something similar:
https://github.com/kastl-ars/wolfi-apkrane

TL;DR: It would be really great to have a README with each action, describing how to use the action. Especially as melange-build-package is running "on the host" aka the Github Runner (and therefore needs the setup-melange action) while e.g. apko-publish runs inside a container...

See here. This probably started failing on ubuntu-latest (there is a runner image update happening) due to some docker upgrade?

Error from server (parsing address pool config: invalid CIDR "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250" in pool "config": invalid IP range "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250": invalid start IP "fc00:f853:ccd:e793::/64.255.1"): error when creating "./metallb-crds.yaml": admission webhook "ipaddresspoolvalidationwebhook.metallb.io" denied the request: parsing address pool config: invalid CIDR "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250" in pool "config": invalid IP range "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250": invalid start IP "fc00:f853:ccd:e793::/64.255.1"

Getting the net config is not valid anymore as it needs to use the second index.
The following should do the trick (tested locally), not sure about compatibility across envs:

"$(docker network inspect kind -f '{{.IPAM.Config}}' |  grep -Po '(\d+\.){3}\d+' | head -n 1 | cut -d '.' -f1,2)"