Skip to content

v0.5.0

Choose a tag to compare

View all tags
@miki725 miki725 released this 08 Jan 23:35
· 143 commits to main since this release
v0.5.0
This tag was signed with the committer’s verified signature.
miki725 Miroslav Shubernetskiy
GPG key ID: 991175EBA30A4DAD
Verified
Learn about vigilant mode.
7eb556c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Download binaries at https://crashoverride.com/downloads

Breaking Changes

  • Changes to docker image related fields.

    Removed keys:

    • _IMAGE_DIGEST - there are cases when the image digest is mutated. For example docker pull && docker push drops all manifest annotations resulting in a change to the digest. It is recommended to use _REPO_DIGESTS instead as it will include all digests per repository.
    • _IMAGE_LIST_DIGEST - it is possible to create manifests outside the build context which results in multiple list manifests for the same image. The new _REPO_LIST_DIGESTS key provides a list of all digests per repository.

    Changed keys:

    • _REPO_DIGESTS previously (and incorrectly) would return the first registry and the image digest. This key now provides a list of image digests by registry and image name.

      Before:

      {
  // old format
  "_REPO_DIGESTS": {
    "224111541501.dkr.ecr.us-east-1.amazonaws.com/co/chalketl/scripts": "249ce02d7f5fe0398fc87c2fb6c225ef78912f038f4be4fe9c35686082fe3cb0"
  }
}

      Now:

      {
  // new format
  "_REPO_DIGESTS": {
    "registry-1.docker.io": {
      "library/alpine": [
        "029a752048e32e843bd6defe3841186fb8d19a28dae8ec287f433bb9d6d1ad85"
      ]
    }
  }
}

    • _REPO_TAGS now includes tags which are only available in the registry. Builds without --push, even when provided with --tag, will not populate _REPO_TAGS anymore. In addition similarly to _REPO_DIGESTS, it is an object where each tag is associated with its digest (either list or image digest). For example:

      {
  "_REPO_TAGS": {
    "registry-1.docker.io": {
      "library/alpine": {
        "latest": "1e42bbe2508154c9126d48c2b8a75420c3544343bf86fd041fb7527e017a4b4a"
      }
    }
  }
}

    • DOCKER_BASE_IMAGES - sub-keys:

      • name renamed to uri; contains the full repository uri (tag and digest)
      • new registry key; the normalized registry uri (domain and optional port)
      • new name key; the normalized repo name within the registry

      Before:

      // old format
{
  "from": "nginx:1.27.0",
  "tag": "1.27.0",
  "name": "nginx:1.27.0",
  "repo": "nginx"
}

      Now:

      // new format
{
  "from": "nginx:1.27.0@sha256:97b83c73d3165f2deb95e02459a6e905f092260cd991f4c4eae2f192ddb99cbe",
  "uri": "nginx:1.27.0@sha256:97b83c73d3165f2deb95e02459a6e905f092260cd991f4c4eae2f192ddb99cbe",
  "repo": "nginx",
  "registry": "registry-1.docker.io",
  "name": "library/nginx",
  "tag": "1.27.0",
  "digest": "97b83c73d3165f2deb95e02459a6e905f092260cd991f4c4eae2f192ddb99cbe"
}

    • DOCKER_COPY_IMAGES - similar to DOCKER_BASE_IMAGES, the name key has been renamed to uri and adds the registry and name keys.

    New keys:

    • _REPO_LIST_DIGESTS - similar to _REPO_DIGESTS but enumerates any known list digests. Example:

      {
  "_REPO_LIST_DIGESTS": {
    "registry-1.docker.io": {
      "library/alpine": [
        "1e42bbe2508154c9126d48c2b8a75420c3544343bf86fd041fb7527e017a4b4a"
      ]
    }
  }
}

    • _REPO_URLS - similar to _REPO_DIGESTS but shows human-accessible URL, if known as per OCI image annotation or computed for Docker Hub images. Example:

      {
  "_REPO_URLS": {
    "registry-1.docker.io": {
      "library/alpine": "https://hub.docker.com/_/alpine"
    }
  }
}

    NOTE: All _REPO_* keys normalize registry to its canonical domain. For example, docker hub is normalized to registry-1.docker.io. Additionally, all image names are normalized to how they are stored in the registry. Note library/ prefix for alpine in the example above.

    (#450, #453, #464)

  • Git time-related fields are now reported in ISO-8601 format whereas previously it was reporting using default git format.

    Before:

    {
  "DATE_AUTHORED": "Tue Dec 10 11:46:06 2024 -0500",
  "DATE_COMMITTED": "Tue Dec 10 11:46:06 2024 -0500",
  "DATE_TAGGED": "Tue Dec 10 11:46:06 2024 -0500"
}

    Now:

    {
  "DATE_AUTHORED": "2024-12-10T16:46:06.000Z",
  "DATE_COMMITTED": "2024-12-10T18:49:00.000Z",
  "DATE_TAGGED": "2024-12-10T18:49:00.000Z"
}

    This also affects all host-level keys in addition to chalk-level keys:

    • DATE_AUTHORED
    • DATE_COMMITTED
    • DATE_TAGGED
    • _DATE_AUTHORED
    • _DATE_COMMITTED
    • _DATE_TAGGED

    To make parsing easier, in addition to human readable DATE_* fields, new TIMESTAMP_* fields are added which report milliseconds since Unix epoch:

    {
  "DATE_AUTHORED": "2024-12-10T16:46:06.000Z",
  "DATE_COMMITTED": "2024-12-10T18:49:00.000Z",
  "DATE_TAGGED": "2024-12-10T18:49:00.000Z",
  "TIMESTAMP_AUTHORED": 1733849166000,
  "TIMESTAMP_COMMITTED": 1733856540000
  "TIMESTAMP_TAGGED": 1733856540000
}

    (#458)

  • All datetime fields are now reported in UTC TZ whereas previously were reported in machines local TZ (#458)

Fixes

  • DOCKERFILE_PATH_WITHIN_VCTL key is no longer reported when providing Dockerfile contents via stdin (#454).

  • Git time-related fields report accurate timezone now. Previously wrong commit TZ was being reported as committed in git which was not correct. (#458)

  • _OP_ERRORS includes all logs from chalkmark ERR_INFO, even when its collection fails (#459)

  • docker buildx build without both --push or --load report their chalkmarks now. Chalkmarks however are missing any runtime keys as those cannot be inspected due to image neither being pushed to a registry or loaded into local daemon. Such an image is normally inaccessible however it is still in buildx cache hence it can be used in subsequent builds. (#459)

New Features

  • Chalk pins base images in Dockerfile. For example:

    FROM alpine

    Will be pinned to:

    FROM alpine@sha256:beefdbd8a1da6d2915566fde36db9db0b524eb737fc57cd1367effd16dc0d06d

    This makes docker build deterministic and avoids any possible race conditions between chalk looking up metadata about base image and actual docker build. (#449)

  • Docker annotations new keys:

    • DOCKER_ANNOTATIONS - all --annotations using in docker build
    • _IMAGE_ANNOTATIONS - found annotations for an image in registry

    (#452)

  • Docker base image keys:

    • _OP_ARTIFACT_CONTEXT - what is the context of the artifact. For docker build its either build or base.
    • DOCKER_BASE_IMAGE_REGISTRY - just registry of the base image
    • DOCKER_BASE_IMAGE_NAME - repo name within the registry
    • DOCKER_BASE_IMAGE_ID - image id (config digest) of the base image
    • DOCKER_BASE_IMAGE_METADATA_ID - id of the base image chalkmark
    • `DOCKER_BASE_IMAGE_CHALK`` - full chalkmark of base image
    • _COLLECTED_ARTIFACTS - similar to _CHALKS but reports collected information about potentially non-chalked artifacts such as the base image. If the base image is chalked it can be correlated with the build chalkmark via METADATA_ID. Otherwise both artifacts can be linked via the digest or the image id.

    (#453, #463)

  • _IMAGE_LAYERS key which collects image layer digests as it is stored in the registry. This should allow to correlate base images by matching layer combinations from other images. (#456)

  • _DOCKER_USED_REGISTRIES - Configurations about all used docker registires during chalk operation. For example:

    {
  "_DOCKER_USED_REGISTIES" {
    "example.com:5044": {
      "url": "https://example.com:5044/v2/",
      "mirroring": "registry-1.docker.io",
      "source": "buildx",
      "scheme": "https",
      "http": false,
      "secure": true,
      "insecure": false,
      "auth": true,
      "www_auth": false,
      "pinned_cert_path": "/etc/buildkit/certs/example_com_5044/ca.crt",
      "pinned_cert": "-----BEGIN CERTIFICATE-----\n..."
    }
  }
}

    (#461)

Commits since the previous tag: v0.4.14...v0.5.0

Assets 2
Loading