gimlet-io / gimletd Goto Github PK

Add a new command to Gimlet CLI once the schema is defined in #2

My experience shows that traversing and filtering git history becomes slow even for trivial number of commits.

The previous - closed source - implementation of Gimlet got slow for querying release history of a given pair of environment and application when the total commit count of the GitOps repository reached 1-3000 commits.
The implementation used https://github.com/go-git/go-git and the slowness perhaps related to go-git/go-git#137

This issue is meant to investigate go-git performance in synthetic tests also comparing it to the git binary.

Extend the deploy logic to be able to trigger on branch and tag name patterns:

deploy:
  event: push
  branch: "feature/*"

deploy:
  event: tag
  branch: "v*"

pointer where the triggers are evaluated: https://github.com/gimlet-io/gimletd/blob/main/worker/gitops_test.go#L87

A servers-side function to perform gimlet gitops delete on the gitops repo

GimletD assumes all release focused tasks and the management of the GitOps repository. These responsibilities used to be part of CI pipelines, therefor GimletD needs to break those out from CI. It achieves it by introducing a new concept, the release artifact. It serves as the means to detach release workflows from CI.

With GimletD instead of releasing, CI generates a release artifact for each releasable version of the application which will be released by GimletD. See the whole flow on the Concepts page.

The artifact is a large JSON object that contains all metadata that can be later used for releasing and auditing. But it is quite cumbersome to collect all metadata from CI pipelines with a series of Gimlet CLI calls:

• gimlet artifact create to create an initial JSON file with the git version information
• gimlet artifact add to add fields like
  • CI job url
  • docker image name
  • gimlet environment manifests
  • environment variables
• gimlet artifact push to ship it to GimletD

This series of steps is best packaged together in a CI plugin.

One such plugin already exists for CircleCI. The task is to make one for Github Actions

With the latest flux we can use the spec.wait flag that

bool | (Optional) Wait instructs the controller to check the health of all the reconciled resources. When enabled, the HealthChecks are ignored. Defaults to false.

https://fluxcd.io/docs/components/kustomize/api/#kustomize.toolkit.fluxcd.io/v1beta2

Must use v1beta2 for the Kustomization resource for this flag to work

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization

.gimlet/preview.yaml

app: frontend-{{ .BRANCH }}
env: preview
namespace: my-team
deploy:
  branch: feature/*
  event: push
+ cleanup:
+   app: frontend-{{ .BRANCH }}
+   event: branch-deleted

Currently the installation instruction only shows example that uses OneChart's sealedFileSecrets feature.
This mandates to have Sealed Secrets installed, which raises the bar significantly.

The task is to add an example that works with plain secrets / env vars / anything.

Right now an artifact is tied to a repo and git sha.
We should introduce a logical app concept to be able to control which apps need to be released from a monorepo.

Define the release artifact schema as per https://github.com/gimlet-io/gimletd/blob/main/docs/design.md

https://github.com/gimlet-io/gimletd/blob/main/worker/gitops_test.go#L290

should be documented here:

https://gimlet.io/gimletd/policy-based-releases/

Grafana puts it to a k8s secret.

We could follow a similar practice.

Gimletd leaves modified files in the gitops repo cache in case of an error

When someone defines a pvc, or an ingress in an app, deploys it, Gimletd puts all resources to the gitops repo. ✔️

When then someone deletes the pvc from the gimlet manifest, Gimletd doesn't remove the file from the gitops repo ❌

This is a bug.

If the branch deleted detector faces a git issue, it clears its working copy and won't be able to detect branch deletions.

Git issues often pop up in the form of object not found due to force pushes (?)