chainguard-dev / actions Goto Github PK
View Code? Open in Web Editor NEWA collection of reusable Github Actions workflows.
License: Apache License 2.0
A collection of reusable Github Actions workflows.
License: Apache License 2.0
See: #35
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
We should spin up 1.26 clusters in e2e
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
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
registry.terraform.io only has chainguard-dev.
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)"
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.
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}"
Here is how to list releases.
gh api /repos/spdx/tools-java/releases --jq '.[] | ."name" + ":" + (."id"|tostring)'
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
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.
actions/setup-registry/README.md
Line 26 in 515343e
actions/apko-build/action.yaml
Line 65 in 1b42233
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.
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
actions/setup-kind/action.yaml
Line 155 in c9b5c5e
$ 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.
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
@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
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
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
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-check
we can use instead.This seems like a potentially useful piece of information, especially for debugging issues related to removing CRDs that use finalizers.
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.
I noticed this in some runs that had early failures, there seems to be a loop polling grafana, which doesn't exist.
cc @cpanato
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.
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...
Sometimes it's desireable to not have to specify the exact version of the, say knative version. Some reasons are:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.