kubernetes-sigs / zeitgeist

Zeitgeist: the language-agnostic dependency checker

Zeitgeist

(/ˈzaɪtɡaɪst/) is a language-agnostic dependency checker that keeps track of external dependencies across your project and ensure they're up-to-date.

• Rationale
• What is Zeitgeist
• Installation
• Supported upstreams
• Supported version schemes
• When is Zeitgeist not suggested
• Naming
• Releasing
• Credit
• To do
• Community, discussion, contribution, and support
  • Code of conduct

Rationale

More and more projects nowadays have external dependencies, and the best way to ensure stability and reproducibility is to pin these dependencies to a specific version.

However, this leads to a new problem: the world changes around us, and new versions of these dependencies are released all the time.

For a simple project with a couple of dependencies, a team can usually keep up to speed by following mailing lists or Slack channels, but for larger projects this becomes a daunting task.

This problem is pretty much solved by package managers in specific programming languages (see When is Zeitgeist not suggested below), but it remains a big issue when:

• Your project relies on packages outside your programming language of choice
• You declare infrastructure-as-code, where the "build step" is usually bespoke and dependencies are managed manually
• Dependencies do not belong in a classical "package manager" (e.g. AMI images)

What is Zeitgeist

Zeitgeist is a tool that takes a configuration file with a list of dependencies, and ensures that:

• These dependencies versions are consistent within your project
• These dependencies are up-to-date

A Zeitgeist configuration file (usually dependencies.yaml) is a list of dependencies, referenced in files, which may or may not have an upstream:

dependencies:
- name: terraform
  version: 0.12.3
  upstream:
    flavour: github
    url: hashicorp/terraform
  refPaths:
  - path: helper-image/Dockerfile
    match: TERRAFORM_VERSION
  - path: .github/actions/run.yaml
    match: terraform
- name: aws-eks-ami
  version: ami-09bbefc07310f7914
  scheme: random
  upstream:
    flavour: ami
    owner: amazon
    name: "amazon-eks-node-1.21-*"
  refPaths:
  - path: clusters.yaml
    match: workers_ami

Use zeitgeist validate to verify that the dependency version is correct in all files referenced in refPaths, and whether any newer version is available upstream:

You can also use zeitgeist upgrade to go ahead and upgrade your dependencies to the latest versions detected by Zeitgeist.

Installation

You will need to build Zeitgeist from source (for now at least!).

Clone the repository and run go build will give you the zeitgeist binary.

To build the local-only binary:

git clone https://github.com/kubernetes-sigs/zeitgeist.git
cd zeitgeist/
go build

To build a binary capable of inspecting remote upstreams:

git clone https://github.com/kubernetes-sigs/zeitgeist.git
cd zeitgeist/remote/zeitgeist
go build

Supported upstreams

Github

The Github upstream looks at releases from a Github repository.

Example:

dependencies:
- name: terraform
  version: 0.15.3
  upstream:
    flavour: github
    url: hashicorp/terraform
  refPaths:
  - path: testdata/zeitgeist-example/a-config-file.yaml
    match: terraform_version

For API access, you will need to set the following env var:

export GITHUB_TOKEN=<YOUR_GITHUB_TOKEN>

Helm

The Helm upstream looks at chart versions from a Helm repository.

Example:

dependencies:
- name: linkerd
  version: 2.10.0
  upstream:
    flavour: helm
    repo: https://helm.linkerd.io/stable
    chart: linkerd2
  refPaths:
  - path: testdata/zeitgeist-example/a-config-file.yaml
    match: linkerd-

Gitlab

The Gitlab upstream looks at releases from a Gitlab repository.

Example:

dependencies:
- name: gitlab-agent
  version: v14.0.1
  upstream:
    flavour: gitlab
    url: gitlab-org/cluster-integration/gitlab-agent
  refPaths:
  - path: testdata/zeitgeist-example/a-config-file.yaml
    match: GL_VERSION

The Gitlab API requires authentication, so you will need to set an Access Token.

When using the public GitLab instance at https://gitlab.com/ :

export GITLAB_TOKEN=<YOUR_GITLAB_TOKEN>

When using a self-hosted GitLab instance, ie. https://my-gitlab.company.com/ :

export GITLAB_PRIVATE_TOKEN=<YOUR_GITLAB_PRIVATE_TOKEN>

You can use in the dependencies.yaml both public and private GitLab instances. The only limitation today is that you can only use one private GitLab at the moment.

AMI

The AMI upstream looks at Amazon Machine Images from AWS.

Example:

dependencies:
- name: aws-eks-ami
  version: ami-09bbefc07310f7914
  scheme: random
  upstream:
    flavour: ami
    owner: amazon
    name: "amazon-eks-node-1.21-*"
  refPaths:
  - path: testdata/zeitgeist-example/a-config-file.yaml
    match: zeitgeist:aws-eks-ami

It uses the standard go AWS SDK authentication methods for authentication and authorization, so it can be used for both public & private AMIs.

Container

The container upstream talks to OCI container registries, such as Docker registries.

Example:

dependencies:
- name: docker-in-docker
  version: 19.03.15
  upstream:
    flavour: container
    registry: hub.docker.io/docker
  refPaths:
  - path: testdata/zeitgeist-example/a-config-file.yaml
    match: docker-dind

If you're connecting to a private registry, you will need to set the following env vars:

export REGISTRY_USERNAME=<YOUR_REGISTRY_USERNAME>
export REGISTRY_USER_PASSWORD=<YOUR_REGISTRY_TOKEN_PASSWORD>

EKS

The EKS checks for updates to Elastic Kubernetes Service, Amazon's managed Kubernetes offering.

Example:

dependencies:
- name: eks
  version: 1.13.0
  upstream:
    flavour: eks
  refPaths:
  - path: testdata/zeitgeist-example/a-config-file.yaml
    match: eks

Supported version schemes

Zeitgeist supports several version schemes:

• semver: SemVer v2, default
• alpha: alphanumeric ordering. A newer version is considered an update if it's alphanumerically higher, e.g. "release-d" is higher "release-c" but "release-b-update-1" wouldn't be higher than "release-c".
• random: any newer version is considered an update. Useful for UUID or hash-based versioning.

See the full documentation to see configuration options.

When is Zeitgeist not suggested

While Zeitgeist aims to be a great cross-language solution for tracking external dependencies, it won't be as well integrated as native package managers.

If your project is mainly written in one single language with a well-known and supported package manager (e.g. npm, maven, rubygems, pip, cargo...), you definitely should use your package manager rather than Zeitgeist.

Naming

Zeitgeist, a German compound word, can be translated as "spirit of the times" and refers to a schema of fashions or fads which prescribes what is considered to be acceptable or tasteful for an era.

Releasing

Releases are generated with goreleaser.

git tag v0.0.0 # Use the correct version here
git push --tags
export GPG_TTY=$(tty)
goreleaser release --rm-dist

Credit

Zeitgeist is inspired by Kubernetes' script to manage external dependencies and extended to include checking with upstream sources to ensure dependencies are up-to-date.

To do

• Find a good name for the project
• Support helm upstream
• Support eks upstream
• Support ami upstream
• support docker upstream
• Cleanly separate various upstreams to make it easy to add new upstreams
• Implement non-semver support (e.g. for AMI, but also for classic releases)
• Write good docs :)
• Write good tests!
• Externalise the project into its own repo
• Generate releases
• Automate release generation from a tag

Community, discussion, contribution, and support

Learn how to engage with the Kubernetes community on the community page.

You can reach the maintainers of this project at:

• #release-management channel on Kubernetes Slack
• Mailing List

Code of conduct

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.

zeitgeist's Issues

Formatted output for extensibility

What would you like to be added:

I would like to add support for formatted outputs like yaml and json. As mentioned in #21 and #27 Zeitgeist can be used by other systems that rely on the output of Zeitgeist to perform some actions. To allow smoother integrations with other systems, eg: build system, dependency bots, etc, we need a machine readable output.

Example:
For the following dependency.yaml :

dependencies:
- name: terraform 
  version: 0.12.3
  upstream:
    flavour: github
    url: hashicorp/terraform
- name: awesome-cli
  version: 79b5b78183f2585689780fbdef1395b06d05ed25
  scheme: random
  upstream:
    flavour: github
    url: project/awesome-cli
    branch: master

The output (in yaml format) can be :

- name: terraform  # example of a component where a new version is detected
  version: 0.12.3
  nextVersion: 0.14.7 # new version available that satisfies the given constraints
- name: awesome-cli  # example of a component where no new version is detected
  version: 79b5b78183f2585689780fbdef1395b06d05ed25
  nextVersion: 79b5b78183f2585689780fbdef1395b06d05ed25

The output format can be specified by --output-format and the accepted values will be json and yaml.
Would also be better to add a -o flag to support writing the output to a target file. Would default to writing the output to dependency_output.(yaml|json)

Why is this needed:

As mentioned in #21 and #27 Zeitgeist can be used by other systems that rely on the output of Zeitgeist to perform some actions. To allow smoother integrations with other systems, eg: build system, dependency bots, etc, we need a machine readable output.

Additional note:
An issue along the same lines is recorded at #21. This issue will be used to track the efforts on this feature as it is going to cover a broader list of output formats, namely yaml and json.

Zeitgeist sometimes fails to retrieve the latest semver version

Zeitgeist fails to get the latest version when a newer but lower-semver version has been released:

DEBUG[2019-09-17T17:40:19+01:00] Examining dependency: istio
DEBUG[2019-09-17T17:40:19+01:00] Using GitHub flavour
DEBUG[2019-09-17T17:40:19+01:00] GitHub Access Token provided
DEBUG[2019-09-17T17:40:19+01:00] Found latest matching release: 1.1.15
DEBUG[2019-09-17T17:40:19+01:00] No update available for dependency istio: 1.2.0 (latest: 1.1.15)

Add Scott Nichols as a zeitgeist maintainer

What would you like to be added:

Add @n3wscott as a zeitgeist maintainer.

Why is this needed:

From kubernetes/org#2299:

Scott recently donated buoy (https://github.com/n3wscott/buoy) to zeitgeist (https://github.com/kubernetes-sigs/zeitgeist) and we'll be adding his as a maintainer to help integrate the two tools!

Tracking:

• k-sigs org membership request: kubernetes/org#2299
• k/org team updates: kubernetes/org#2300
• Add OWNERS for buoy/: #17
• Promote to approver post-buoy integration:

/assign

Consider adding fields for interpreting a base image or tooltip/description

What would you like to be added:

Fields for interpreting a base image or tooltip/description

Why is this needed:

From @tpepper in kubernetes/release#2081 (comment):

@tpepper -- thanks for the suggestion!
Each of the comments are actually representative of the dependency we're tracking, as in, "these various entries are things you should look at updating when managing the distroless dependency".
In this case, we're saying that you should look at updating

- name: "gcr.io/projectsigstore/cosign"

when updating anything that depends on distroless images.
Do you think there's a better way to represent this in comments?

I'd bumped into this because I was looking at something in go-runner and saw its Dockerfile referenced distroless (as I'd expect for many/most) for "production" images, and was working backwards toward version hints beyond "latest" and was grepping around for distroless things. I figured there are lots of distroless usage points, but then I saw the dependencies.yaml only saying distroless at the cosign usage and got misled by the comment pattern.

Maybe this argues for something like a

- baseimagename: ""

field? This would lead to some repetition in the file, as it puts the dependency explicitly at each dependent site in the file. Today if usage going from a dependency to its base is "visually scan upward to he prior #comment to see the base image name for this dependency" feels somewhat obscure. If the usage is "upon seeing a #comment know that everything following (but before a next comment) shares usage of the base image in this comment" the current way can make sense. The other benefit though of the explicit entry in yaml instead of comments and visual scans is explicit machine readability.

Massive numbers of transitive dependencies (including github.com/hashicorp/go-retryablehttp) required to build

What happened:

Cannot build zeitgeist without pulling in MPL-licensed projects not in the CNCF allowlist.

zeitgeist depends on github.com/xanzy/go-gitlab which pulls in github.com/hashicorp/go-retryablehttp which is MPL-licensed and not included in the CNCF allowlist

https://github.com/cncf/foundation/blob/main/license-exceptions/

https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md#cncf-allowlist-license-policy

cncf/foundation#138

What you expected to happen:

No dependencies on MPL-licensed projects not explicitly allowlisted

Remote client libraries like aws/github/gitlab are not required to build/run the local-only dependency file checks

How to reproduce it (as minimally and precisely as possible):

run go mod vendor to see code actually used/linked by zeitgeist and observe the go-gitlab and go-retryablehttp code is required to build.

Anything else we need to know?:

Environment:

• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Others:

Regex to extract version ?

To my understanding zeitgeist is only supporting correct semver tags. But some containers are tagged like amd64-1.2.1, etc...
It could be nice if we can filter tags based on regex and extract the semver version

Add support for git tags on github/gitlab repositories

What would you like to be added:

Support for git tags as a fallback to github/gitlab repositories that do not utilize the platform specific "Release" features.

Why is this needed:

Some projects on github/gitlab do not have releases and only have tags.
Example:
https://github.com/golang/go/releases

New feature: warning for archived repos

What would you like to be added:

Add a warning when Zeitgeist encounters github repos that have been marked as archived.

Why is this needed:

Github has a feature where repositories can be marked as archived when no further development is planned. Archived repositories become read-only.

This is usually a strong signal that the project is being phased out, and depending on it may not be such a good idea anymore as it will not get any more support.

Having a warning in that case would be great for dependency tracking!

JSON output for extensibility

What would you like to be added:

I would like support for JSON output for exensibility. I think the output should include at least:

The matches (w/ byte offsets) of each version found in different files

This would allow another program to easily change the version tag and run CI or create a PR to bump it (kind of like dependabot). This must be the offsets where the version should be stored, in a consistent with regards to prefixes like "v" and quotes. An alternative to the byte offset would be to have a mode to run this program in to set the version of a named component in the inventory and referenced files.

A more complete set of possible "next version"

It's difficult to say exactly what versions should be included. There are multiple different candidates for upgrading, depending on strategies, so perhaps all versions newer than the current release would be a good idea. For downgrades, I don't think this tool would be used, but more likely a git revert or a hand picked version.
A more compact option would be to include:

• The next patch version (cur + 0.0.1) - if any
• The latest patch version (cur +0.0.(max)) - if any
• The next minor release (cur + 0.1.(max)) - if any
• The latest minor release (cur + 0.(max).(max)) - if any
• The latest major release (cur + (max).(max).(max)) - if any
  Given that we will not have any system for dependencies across components, known buggy versions etc., these are the versions I think I would most likely consider.

Links to changelogs

For humans to review

The timestamp of each release

This could be helpful for deciding if a version is likely unmaintained (time for upgrade to next minor/major) when on the latest patch level.

Why is this needed:

I think this will open up for more automation, like dependabot or CI jobs which fail when using stale patch versions, and also CLI tools to manually run to upgrade components. Some of these features probably should be considered directly in this tool, depending on the scope of the project.

Zeitgeist fails to validate OCI Helm repositories

What happened:

When using an OCI repository as a Helm upstream, like:

dependencies:
  - name: karpenter
    version: 0.22.1
    scheme: semver
    upstream:
      chart: karpenter
      flavour: helm
      repo: oci://public.ecr.aws/karpenter
    refPaths:
      - path: karpenter.tf
        match: zeitgeist:karpenter

Zeitgeist fails:

level=error msg="failed to download index file for repo oci://public.ecr.aws/karpenter"
level=fatal msg="error during command execution: &fmt.wrapError{msg:\"upgrade dependencies: object required\", err:(*errors.errorString)(0xc000b0d850)}"

What you expected to happen:

Zeitgeist ought to work like for non-OCI based Helm repositories.

How to reproduce it (as minimally and precisely as possible):

See above.

Anything else we need to know?:

n/a

Environment:

n/a

Incorrect latest version selected for GitHub upstream

What happened:

When using the GitHub upstream, zeitgeist fails to select the highest version when the most recently created release is not equal to the latest release. For example, https://github.com/containers/buildah/releases currently lists v1.31.4 and v1.29.2 before the latest release, v1.32.2. zeitgeist returns v1.31.4 as the latest version.

What you expected to happen:

The highest version should be selected, not the one released most recently.

How to reproduce it (as minimally and precisely as possible):

I created a test case demonstrating the incorrect behaviour: michaelsauter@f10f89c.

Anything else we need to know?:

Interestingly, the potential issue is described in a code comment, see https://github.com/kubernetes-sigs/zeitgeist/blob/master/upstream/github.go#L103-L108. However, the code below does not seem to address the issue. Further, I found #2, which seems related. It introduces code to fetch all release pages instead of just the first one. Surprisingly, this is missing from https://github.com/kubernetes-sigs/zeitgeist/blob/master/upstream/github.go right now.

Environment:

GitVersion:    v0.4.3
GitCommit:     unknown
GitTreeState:  unknown
BuildDate:     unknown
GoVersion:     go1.21.0
Compiler:      gc
Platform:      darwin/arm64

fails to sort semver higher than non-semver

Currently zeitgeist fails with this dependency input

  - name: cloud-sql-proxy
    version: 2.9.0
    upstream:
      flavour: container
      registry: gcr.io/cloud-sql-connectors/cloud-sql-proxy

• Current cloud-sql-proxy release is 2.11.0, they have tagged both 2.11. and 2.11.0
• upstream/container.go accepts both tags as valid versions, and decides 2.11 is the highest version found and returns that
• as described in #859, dependency/version.go will later fail because it requires an actual semver version: 2.11 is not good enough

DEBU Using Container flavour                       file="upstream/container.go:43"
DEBU Retrieving tags for gcr.io/cloud-sql-connectors/cloud-sql-proxy...  file="upstream/container.go:60"
DEBU Found 122 tags for gcr.io/cloud-sql-connectors/cloud-sql-proxy...  file="upstream/container.go:65"
DEBU Error parsing version 2-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.10-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.10-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.10-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.11-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.11-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.11-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.6-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.6-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.6-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.7-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.7-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.7-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.8-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.8-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.8-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.9-alpine (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.9-bullseye (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version 2.9-buster (Short version cannot contain PreRelease/Build meta data) as semver  file="upstream/container.go:76"
DEBU Error parsing version alpine (Invalid character(s) found in major number "0alpine") as semver  file="upstream/container.go:76"
DEBU Error parsing version bullseye (Invalid character(s) found in major number "0bullseye") as semver  file="upstream/container.go:76"
DEBU Error parsing version buster (Invalid character(s) found in major number "0buster") as semver  file="upstream/container.go:76"
DEBU Error parsing version latest (Invalid character(s) found in major number "0latest") as semver  file="upstream/container.go:76"
DEBU Found latest matching tag: 2.11               file="upstream/container.go:95"
DEBU Failed to semver-parse 2.11                   file="dependency/version.go:99"
FATA error during command execution: &errors.errorString{s:"No Major.Minor.Patch elements found"}  file="zeitgeist/main.go:32"

There seems to be a plan to add some more configuration in #859 to handle the more generic case but I think this specific failure is an actual bug: the sorting order is wrong as the "real semver" should sort higher than the "not strict semver".

I will send a PR

Assimilate the features of buoy into zeitgeist

What would you like to be added:

Understanding golang/go mod dependencies for release families.

Why is this needed:

Why have two tools that have a similar scope!

Zeitgeist should not assume that the config directory is the same as the search directory

What happened:

While working on kubernetes/kubernetes#98845 to integrate zeitgeist into kubernetes/kubernetes, I noticed the following path bug in zeitgeist:

ERRO Error opening /home/prow/go/src/k8s.io/kubernetes/build/test/images/agnhost/VERSION: open /home/prow/go/src/k8s.io/kubernetes/build/test/images/agnhost/VERSION: no such file or directory 
FATA open /home/prow/go/src/k8s.io/kubernetes/build/test/images/agnhost/VERSION: no such file or directory 
+++ exit code: 1
+++ error: 1
FAILED   verify-external-dependencies-version.sh	82s 

The dependencies.yaml for kubernetes/kubernetes is in build/ and because of that, it assumed that test/images/agnhost/VERSION was a subdirectory of the build/ directory, instead of the root of the directory.

Carlos, want to take a look into fixing that?
/assign @cpanato

Release a Zeitgeist docker image?

What would you like to be added:

During releases, we build Go binaries of Zeitgeist, and also create Docker containers that we push to Github registry.

This registry (located at https://github.com/kubernetes-sigs/zeitgeist/pkgs/container/zeitgeist%2Fzeitgeist ) is currently private however.

I'd really like to have publicly-accessible Zeitgeist containers, should we:

• Make the ghcr public? (I don't have the permissions to do that)
• Push the images to another public registry instead?

I'm happy to align with what other sigs projects are doing to make things easier :)

Why is this needed:

"Needed" is a big word, but it'd definitely be a nice to have!

Add support for upgrading a single dependency - to support dependabot/renovate like workflows

What would you like to be added:

One of the following:

1. zeitgeist upgrade [dependency-name]
2. zeitgeist upgrade [dependency-name1...] [dependency-name2...]
3. zeitgeist upgrade [dependency-fnmatch1...] [dependency-fnmatch2...]

I think the first option is simplest and it can be extended to the two other options if needed anyway

It can also support up/downgrading to a specific version like zeitgeist upgrade kustomize --to-version=5.0.3, but that may be better handled by a command like zeitgeist set-version [dependency-name] [version]

Why is this needed:

I would like to have a scheduled job that creates PRs like dependabot for our GitOps based repository with Kustomize yaml files or anything else that dependabot/renovate does not support with the flexibility zeitgeist gives us.

I can implement the code, but I've created this issue so we can agree on the correct design first. Maybe it's best to start with set-version?

Add support to look for new commits in a branch for git repos

What would you like to be added:

Zeitgeist should also support looking up for new commits on branch in a git repo.

Why is this needed:

The --remote feature of Zeitgeist is used by some systems to monitor for availability of new changes/versions of multiple projects.
Automated builds systems are an example of such systems. Automated build systems might choose to monitor a collection of projects to make new builds. The triggers for such systems can include being able to monitor for changes to a branch of a git project.
Adding the support to look for/monitor changes to a git branch through zeitgeist will allow of a system to monitor a collection of projects (git projects) and resources (AMIs) in a unified way.
Example:

dependencies:
- name: awesome-cli
  version: 79b5b78183f2585689780fbdef1395b06d05ed25
  scheme: random
  upstream:
    flavour: github
    url: project/awesome-cli
    branch: master
- name: terraform
  version: 0.12.3
  upstream:
    flavour: github
    url: hashicorp/terraform
- name: fluentd-chart
  version: 2.1.1
  sensitivity: major
  upstream:
    flavour: helm
    repo: stable
    name: fluentd
- name: aws-eks-ami
  version: ami-09bbefc07310f7914
  scheme: random
  upstream:
    flavour: ami
    owner: amazon
    name: "amazon-eks-node-1.13-*"

Using a configuration like this a system can be used to detect changes to any of the interested projects and perform corresponding actions.

semver.Parse vs semver.ParseTolerant

What happened:

Our zeitgeist validate workflow randomly stopped today with the error:

level=fatal msg="error during command execution: &fmt.wrapError{msg:\"checking remote dependencies: No Major.Minor.Patch elements found\", err:(*errors.errorString)(0xc000e16010)}"
level=fatal msg="error during command execution: &errors.errorString{s:\"No Major.Minor.Patch elements found\"}"

What you expected to happen:

1. Include context (dependency name) in the error:

diff --git a/dependency/dependency.go b/dependency/dependency.go
index d6a3eaa..a17c001 100644
--- a/dependency/dependency.go
+++ b/dependency/dependency.go
@@ -527,12 +527,12 @@ func (c *Client) checkUpstreamVersions(deps []*Dependency) ([]versionUpdateInfo,
                }
 
                if err != nil {
-                       return nil, err
+                       return nil, fmt.Errorf("dependency %s: %w", dep.Name, err)
                }
 
                updateAvailable, err := latestVersion.MoreSensitivelyRecentThan(currentVersion, dep.Sensitivity)
                if err != nil {
-                       return nil, err
+                       return nil, fmt.Errorf("dependency compare %s: %w", dep.Name, err)
                }
 
                latestVersion.Version = formatVersion(currentVersion.Version, latestVersion.Version)

FATA error during command execution: &fmt.wrapError{msg:"checking remote dependencies: dependency compare renovate: No Major.Minor.Patch elements found", err:(*fmt.wrapError)(0xc000d72800)} 

2. Don't fail on this. It's because the container check accepts version numbers "tolerantly" while the compare during upgrade does a strict parse. I think we should either always use strict, or always tolerant, or have a feature toggle if really needed.

diff --git a/dependency/version.go b/dependency/version.go
index b4d70d4..02908c2 100644
--- a/dependency/version.go
+++ b/dependency/version.go
@@ -94,13 +94,13 @@ func (a Version) MoreSensitivelyRecentThan(b Version, sensitivity VersionSensiti
 
        switch a.Scheme {
        case Semver:
-               aSemver, err := semver.Parse(strings.TrimPrefix(a.Version, "v"))
+               aSemver, err := semver.ParseTolerant(strings.TrimPrefix(a.Version, "v"))
                if err != nil {
                        log.Debugf("Failed to semver-parse %s", a.Version)
                        return false, err
                }
 
-               bSemver, err := semver.Parse(strings.TrimPrefix(b.Version, "v"))
+               bSemver, err := semver.ParseTolerant(strings.TrimPrefix(b.Version, "v"))
                if err != nil {
                        log.Debugf("Failed to semver-parse %s", b.Version)
                        return false, err

Result:

Update available for dependency renovate: 37.214 (current: 37.198.0)

How to reproduce it (as minimally and precisely as possible):

  - name: renovate
    version: 37.198.0
    scheme: semver
    upstream:
      flavour: container
      registry: ghcr.io/renovatebot/renovate
    refPaths:
      - path: components/renovate/cronjob.yaml
        match: 'renovatebot/renovate:'

Anything else we need to know?:

This didn't happen last week, so I guess it randomly occurs depending on the order of tags from the GHCR API (for example, is 37.198 returned before or after 37.198.0)

Environment:

N/A

zeitgeist v0.4.1 version prints to stderr not stdout breaking release-utils/mage

See also kubernetes-sigs/release-utils#96 and my reproducer and notes here https://github.com/pnasrat/magedep

This probably would need a new version of zeitgeist cut past the commit identified below

What happened:

Error: ensuring zeitgeist is installed: ensuring package: the output of /home/pnasrat/workspace/bin/zeitgeist version did not include a 3-part semver value: 
exit status 1

What you expected to happen:

No error.

How to reproduce it (as minimally and precisely as possible):

1. rm -f "${GOPATH}"/bin/zeitgeist
2. go install sigs.k8s.io/[email protected]
3. zeitgeist version 2>/dev/null

Expect to have the version printed however it is not as it is writing to stderr

Analysis

[email protected] version writes it's version info to stderr which is not what uwu-tools/magex expects in GetCommandVersion see https://github.com/uwu-tools/magex/blob/v0.10.0/pkg/install.go#L288

This can be demonstrated with $GOPATH/bin/zeitgeist version 2>/dev/null

This is fixed in zeitgeist from PR 544 onwards commit: 5108cb4

I used git bisect to identify where the change is and that can be verified

git checkout 5108cb4
go run main.go version 2>/dev/null
 __  /   ____|  _ _|  __ __|    ___|   ____|  _ _|    ___|   __ __|
    /    __|      |      |     |       __|      |   \___ \      |
   /     |        |      |     |   |   |        |         |     |
 ____|  _____|  ___|    _|    \____|  _____|  ___|  _____/     _|
zeitgeist: Zeitgeist is a language-agnostic dependency checker

GitVersion:    devel
GitCommit:     unknown
GitTreeState:  unknown
BuildDate:     unknown
GoVersion:     go1.21.3
Compiler:      gc
Platform:      linux/amd64

Versus the revision before a98a760 which outputs to stderr

git checkout a98a760
go run main.go  version 2>/dev/null

Method RemoteExport() does not filter out up-to-date dependencies

What happened:

I'm leveraging this project as a library and attempting to use RemoteExport() to get a list of dependencies that have new versions. Using RemoteCheck() (which is used by the CLI) filters properly.

What you expected to happen:

Provided the same inputs, RemoteExport() and RemoteCheck() should have the same number of items returned (just different types).

How to reproduce it (as minimally and precisely as possible):

Perhaps my assumptions for what the method should be doing, but the behavior is baked into the tests. I would assume that given the inputs for this test, that their should be no updates being returned, so no assertions should be made against the output.

Anything else we need to know?:

My assumptions for the behavior of the method could be wrong, although it looks as if the logic to build the return list has a conditional with two logic branches that do the same thing.

Environment:

• Cloud provider or hardware configuration: n/a
• OS (e.g: cat /etc/os-release): n/a
• Kernel (e.g. uname -a): n/a
• Others: