Skip to content

Latest commit

 

History

History
192 lines (141 loc) · 7.78 KB

README.adoc

File metadata and controls

192 lines (141 loc) · 7.78 KB
Raw

Updatecli

updatecli:matrix GitHub Go Report Card GitHub Releases GitHub Releases GitHub Workflow Status OpenSSF Scorecard OpenSSF Best Practices

"Automatically open a PR on your GitOps repository when a third party service publishes an update"

Updatecli is a tool used to apply file update strategies. Designed to be used from everywhere, each application "run" detects if a value needs to be updated using a custom strategy then apply changes according to the strategy.

You describe your update strategy in a file then you run updatecli to it.

Updatecli reads a yaml or a go template configuration file, then works into three stages

  1. Sources: Based on a rule, updatecli fetches a value that will be injected in later stages such as latest application version.

  2. Conditions: Ensure that conditions are met based on the value retrieved during the source stage.

  3. Targets: Update and publish the target files based on a value retrieved from the source stage.

Feature

  • Flexibility: Easy to define tailored update strategies, you are just one yaml file from it.

  • Portability: Easy to add to your workflow whatever it is. Just one command to run. Of course, it’s easy to remove.

  • Extensibility: Easy to add new go packages to support more workflows.

Why

There are already many projects out there to continuously update your files, but they all have an opinionated way of doing it and they often want you to adopt a new platform. Building and distributing software is a difficult task and good practices constantly evolve. Updatecli was built to work independently of the underlying dependencies to update, wherever you need it and combining whatever workflow you are using, as you can see in the following section.

Demo

Asciinema

The Quick-start is available on www.updatecli.io/docs/prologue/quick-start

Installation

Updatecli is a Go binary available for Linux, MacOS and Windows from the release page or installed via other methods.

Verify File Checksum Signature

Instead of signing all release assets, Updatecli signs the checksums file containing the different release assets checksum. You can download/copy the three files 'checksums.txt.pem', 'checksums.txt.sig', 'checksums.txt' from the latest release. Once you have the three files locally, you can execute the following command

COSIGN_EXPERIMENTAL=1 cosign verify-blob --cert checksums.txt.pem --signature checksums.txt.sig checksums.txt

A successful output looks like

tlog entry verified with uuid: 73f57e4c16b830ccb615e00814a3481a33365bf48f9bba1c1588886b3344d0ec index: 9085154
Verified OK

Now you can verify the assets checksum integrity.

Verify File Checksum Integrity

Before verifying the file integrity, you should first verify the checksum file signature. Once you’ve download both the checksums.txt and your binary, you can verify the integrity of your file by running:

sha256sum --ignore-missing -c checksums.txt

Verify Container signature

docker pull updatecli/updatecli:vx.y.z
cosign verify updatecli/updatecli@sha256:<image_digest>

Documentation

The documentation of Updatecli is available at www.updatecli.io, but you can also look at the examples section to get an overview.

Example

This example is copy of the quickstart. You can also find it on www.updatecli.io/docs/prologue/quick-start

We define an update strategy in "updatecli.yaml" then we run updatecli apply --config updatecli.yaml. Our objective is to know if the Jenkins project published a new stable version, if they build an appropriated docker image specifically for jdk11 and automatically update our infrastructure accordingly.

## updatecli.yaml
title: Update Jenkins Version

scms:
  default:
    kind: github
    spec:
      user: olblak
      email: [email protected]
      owner: olblak
      repository: charts
      token: mySecretTokenWhichShouldNeverUsedThisWay
      username: olblak
      branch: main

sources:
  jenkins:
    name: Get latest Jenkins version
    kind: jenkins
    spec:
      release: weekly

conditions:
  docker:
    name: "Test if Docker Image Published on Registry"
    kind: dockerimage
    spec:
      image: jenkins/jenkins
      architecture: amd64

targets:
  bumpJenkins:
    name: jenkins/jenkins docker tag
    scmID: default
    kind: yaml
    spec:
      file: charts/jenkins/values.yaml
      key: jenkins.controller.imageTag

actions:
  default:
    title: Open a GitHub pull request with new Jenkins version
    kind: github/pullrequest
    scmID: default
    target:
      - bumpJenkins
    spec:
      automerge: true
      mergemethod: squash
      labels:
        - dependencies

What it says:

  1. Sources:
    What’s the latest jenkins weekly version?
    ⇒ 2.335

  2. Conditions:
    Is there a docker image "jenkins/jenkins" from Dockerhub with the tag "2.335"
    ⇒ Yes then proceed otherwise abort

  3. Targets:
    Do we have to update the key "jenkins.controller.imageTag" from file "./charts/jenkins/values.yaml" located on the Github repository olblak/charts to "2.335"?
    ⇒ If yes then execute the action default opening a GitHub pull request to the "main" branch

More information here

Contributing

As a community-oriented project, all contributions are greatly appreciated!

Here is a non-exhaustive list of possible contributions:

  • ⭐️ this repository.

  • Propose a new feature request.

  • Highlight an existing feature request with 👍.

  • Contribute to any repository in the updatecli organization

  • Share the love

More information available at CONTRIBUTING

Conferences

  • 2022

    • CDcon (US) - Dependency Management: Where the Fork are We? Video

  • 2023

    • FOSDEM (BE) - Cloud Native Dependencies Video