Merge pull request #763 from fluxcd/ghcr

Publish multi-arch image to GitHub Container Registry

.github/workflows/release.yml

@@ -41,6 +41,8 @@ jobs:
           context: .
           file: ./Dockerfile
           platforms: linux/amd64,linux/arm64,linux/arm/v7
+          build-args: |
+            REVISON=${{ github.sha }}
           tags: |
             ghcr.io/fluxcd/flagger:${{ steps.prep.outputs.VERSION }}
           labels: |

.goreleaser.yml

@@ -12,7 +12,3 @@ archives:
   - name_template: "{{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}"
     files:
     - none*
-changelog:
-  filters:
-    exclude:
-      - '^CircleCI'

Dockerfile

@@ -1,6 +1,7 @@
 FROM golang:1.15-alpine as builder
 
 ARG TARGETPLATFORM
+ARG REVISON
 
 WORKDIR /workspace
 
@@ -16,7 +17,9 @@ COPY cmd/ cmd/
 COPY pkg/ pkg/
 
 # build
-RUN CGO_ENABLED=0 go build -a -o flagger ./cmd/flagger
+RUN CGO_ENABLED=0 go build \
+    -ldflags "-s -w -X github.com/fluxcd/flagger/pkg/version.REVISION=${REVISON}" \
+    -a -o flagger ./cmd/flagger
 
 FROM alpine:3.12
 

Makefile

@@ -3,14 +3,7 @@ VERSION?=$(shell grep 'VERSION' pkg/version/version.go | awk '{ print $$4 }' | t
 LT_VERSION?=$(shell grep 'VERSION' cmd/loadtester/main.go | awk '{ print $$4 }' | tr -d '"' | head -n1)
 
 build:
-	GIT_COMMIT=$$(git rev-list -1 HEAD) && CGO_ENABLED=0 GOOS=linux go build  \
-		-ldflags "-s -w -X github.com/fluxcd/flagger/pkg/version.REVISION=$${GIT_COMMIT}" \
-		-a -installsuffix cgo -o ./bin/flagger ./cmd/flagger/*
-	docker build -t weaveworks/flagger:$(TAG) . -f Dockerfile
-
-push:
-	docker tag fluxcd/flagger:$(TAG) fluxcd/flagger:$(VERSION)
-	docker push fluxcd/flagger:$(VERSION)
+	CGO_ENABLED=0 go build -a -o ./bin/flagger ./cmd/flagger
 
 fmt:
 	gofmt -l -s -w ./
@@ -48,13 +41,9 @@ release:
 	git tag "v$(VERSION)"
 	git push origin "v$(VERSION)"
 
-release-notes:
-	cd /tmp && GH_REL_URL="https://github.com/buchanae/github-release-notes/releases/download/0.2.0/github-release-notes-linux-amd64-0.2.0.tar.gz" && \
-    curl -sSL $${GH_REL_URL} | tar xz && sudo mv github-release-notes /usr/local/bin/
-
 loadtester-build:
 	CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o ./bin/loadtester ./cmd/loadtester/*
-	docker build -t fluxcd/flagger-loadtester:$(LT_VERSION) . -f Dockerfile.loadtester
+	docker build -t ghcr.io/fluxcd/flagger-loadtester:$(LT_VERSION) . -f Dockerfile.loadtester
 
 loadtester-push:
-	docker push fluxcd/flagger-loadtester:$(LT_VERSION)
+	docker push ghcr.io/fluxcd/flagger-loadtester:$(LT_VERSION)

artifacts/flagger/deployment.yaml

@@ -22,7 +22,7 @@ spec:
       serviceAccountName: flagger
       containers:
       - name: flagger
-        image: weaveworks/flagger:1.4.2
+        image: ghcr.io/fluxcd/flagger:1.4.2
         imagePullPolicy: IfNotPresent
         ports:
         - name: http

charts/flagger/LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2018 Weaveworks. All rights reserved.
+   Copyright [yyyy] [name of copyright owner]
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

charts/flagger/README.md

@@ -110,7 +110,7 @@ The following tables lists the configurable parameters of the Flagger chart and
 
 Parameter | Description | Default
 --- | --- | ---
-`image.repository` | Image repository | `weaveworks/flagger`
+`image.repository` | Image repository | `ghcr.io/fluxcd/flagger`
 `image.tag` | Image tag | `<VERSION>`
 `image.pullPolicy` | Image pull policy | `IfNotPresent`
 `logLevel` | Log level | `info`

charts/flagger/values.yaml

@@ -1,7 +1,7 @@
 # Default values for flagger.
 
 image:
-  repository: weaveworks/flagger
+  repository: ghcr.io/fluxcd/flagger
   tag: 1.4.2
   pullPolicy: IfNotPresent
   pullSecret:

charts/loadtester/values.yaml

@@ -1,7 +1,7 @@
 replicaCount: 1
 
 image:
-  repository: weaveworks/flagger-loadtester
+  repository: ghcr.io/fluxcd/flagger-loadtester
   tag: 0.18.0
   pullPolicy: IfNotPresent
 

docs/gitbook/README.md

@@ -4,27 +4,19 @@ description: Flagger is a progressive delivery Kubernetes operator
 
 # Introduction
 
-[Flagger](https://github.com/fluxcd/flagger) is a **Kubernetes** operator that automates the promotion of
-canary deployments using **Istio**, **Linkerd**, **App Mesh**, **NGINX**, **Skipper**, **Contour**, **Gloo** or **Traefik** routing for
-traffic shifting and **Prometheus** metrics for canary analysis. The canary analysis can be extended with webhooks for
-running system integration/acceptance tests, load tests, or any other custom validation.
+[Flagger](https://github.com/weaveworks/flagger) is a **Kubernetes** operator that automates the promotion of canary deployments using **Istio**, **Linkerd**, **App Mesh**, **NGINX**, **Skipper**, **Contour**, **Gloo** or **Traefik** routing for traffic shifting and **Prometheus** metrics for canary analysis. The canary analysis can be extended with webhooks for running system integration/acceptance tests, load tests, or any other custom validation.
 
-Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators
-like HTTP requests success rate, requests average duration and pods health.
-Based on analysis of the **KPIs** a canary is promoted or aborted, and the analysis result is published to **Slack** or **MS Teams**.
+Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pods health. Based on analysis of the **KPIs** a canary is promoted or aborted, and the analysis result is published to **Slack** or **MS Teams**.
 
-![Flagger overview diagram](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-overview.png)
+![Flagger overview diagram](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-overview.png)
 
-Flagger can be configured with Kubernetes custom resources and is compatible with any CI/CD solutions made for Kubernetes.
-Since Flagger is declarative and reacts to Kubernetes events,
-it can be used in **GitOps** pipelines together with Flux CD or JenkinsX.
+Flagger can be configured with Kubernetes custom resources and is compatible with any CI/CD solutions made for Kubernetes. Since Flagger is declarative and reacts to Kubernetes events, it can be used in **GitOps** pipelines together with Flux CD or JenkinsX.
 
 This project is sponsored by [Weaveworks](https://www.weave.works/)
 
 ## Getting started
 
-To get started with Flagger, chose one of the supported routing providers
-and [install](install/flagger-install-on-kubernetes.md) Flagger with Helm or Kustomize.
+To get started with Flagger, chose one of the supported routing providers and [install](install/flagger-install-on-kubernetes.md) Flagger with Helm or Kustomize.
 
 After install Flagger, you can follow one of the tutorials:
 
@@ -47,3 +39,4 @@ After install Flagger, you can follow one of the tutorials:
 * [Istio](https://github.com/stefanprodan/gitops-istio)
 * [Linkerd](https://helm.workshop.flagger.dev)
 * [AWS App Mesh](https://eks.handson.flagger.dev)
+

docs/gitbook/SUMMARY.md

@@ -41,3 +41,4 @@
 * [Development Guide](dev/dev-guide.md)
 * [Release Guide](dev/release-guide.md)
 * [Upgrade Guide](dev/upgrade-guide.md)
+

docs/gitbook/dev/dev-guide.md

@@ -2,25 +2,24 @@
 
 This document describes how to build, test and run Flagger from source.
 
-### Setup dev environment
+## Setup dev environment
 
 Flagger is written in Go and uses Go modules for dependency management.
 
 On your dev machine install the following tools:
-* go >= 1.14
-* git >= 2.20
-* bash >= 5.0
-* make >= 3.81
-* kubectl >= 1.16
-* kustomize >= 3.5
-* helm >= 3.0
-* docker >= 19.03
 
-You'll also need a Kubernetes cluster for testing Flagger.
-You can use Minikube, Kind, Docker desktop or any remote cluster
-(AKS/EKS/GKE/etc) Kubernetes version 1.14 or newer.
+* go >= 1.14
+* git >= 2.20
+* bash >= 5.0
+* make >= 3.81
+* kubectl >= 1.16
+* kustomize >= 3.5
+* helm >= 3.0
+* docker >= 19.03
 
-To start contributing to Flagger, fork the [repository](https://github.com/fluxcd/flagger) on GitHub.
+You'll also need a Kubernetes cluster for testing Flagger. You can use Minikube, Kind, Docker desktop or any remote cluster \(AKS/EKS/GKE/etc\) Kubernetes version 1.14 or newer.
+
+To start contributing to Flagger, fork the [repository](https://github.com/weaveworks/flagger) on GitHub.
 
 Create a dir inside your `GOPATH`:
 
@@ -39,7 +38,7 @@ cd flagger
 Set Flagger repository as upstream:
 
 ```bash
-git remote add upstream https://github.com/fluxcd/flagger.git
+git remote add upstream https://github.com/weaveworks/flagger.git
 ```
 
 Sync your fork regularly to keep it up-to-date with upstream:
@@ -50,7 +49,7 @@ git checkout master
 git merge upstream/master
 ```
 
-### Build
+## Build
 
 Download Go modules:
 
@@ -70,7 +69,7 @@ Build load tester binary and container image:
 make loadtester-build
 ```
 
-### Code changes
+## Code changes
 
 Before submitting a PR, make sure your changes are covered by unit tests.
 
@@ -98,7 +97,7 @@ Run unit tests:
 make test
 ```
 
-### API changes
+## API changes
 
 If you made changes to `pkg/apis` regenerate the Kubernetes client sets with:
 
@@ -114,18 +113,17 @@ make crd
 
 Note that any change to the CRDs must be accompanied by an update to the Open API schema.
 
-### Manual testing
+## Manual testing
 
-Install a service mesh and/or an ingress controller on your cluster and deploy Flagger
-using one of the install options [listed here](https://docs.flagger.app/install/flagger-install-on-kubernetes).
+Install a service mesh and/or an ingress controller on your cluster and deploy Flagger using one of the install options [listed here](https://docs.flagger.app/install/flagger-install-on-kubernetes).
 
 If you made changes to the CRDs, apply your local copy with:
 
 ```bash
 kubectl apply -f artifacts/flagger/crd.yaml
 ```
 
-Shutdown the Flagger instance installed on your cluster (replace the namespace with your mesh/ingress one):
+Shutdown the Flagger instance installed on your cluster \(replace the namespace with your mesh/ingress one\):
 
 ```bash
 kubectl -n istio-system scale deployment/flagger --replicas=0
@@ -163,7 +161,7 @@ kubectl -n istio-system scale deployment/flagger --replicas=1
 
 Now you can use one of the [tutorials](https://docs.flagger.app/) to manually test your changes.
 
-### Integration testing
+## Integration testing
 
 Flagger end-to-end tests can be run locally with [Kubernetes Kind](https://github.com/kubernetes-sigs/kind).
 
@@ -204,8 +202,7 @@ Run the Linkerd e2e tests:
 ./test/e2e-linkerd-tests.sh
 ```
 
-For each service mesh and ingress controller there is a dedicated e2e test suite,
-chose one that matches your changes from this [list](https://github.com/fluxcd/flagger/tree/master/test).
+For each service mesh and ingress controller there is a dedicated e2e test suite, chose one that matches your changes from this [list](https://github.com/weaveworks/flagger/tree/master/test).
 
 When you open a pull request on Flagger repo, the unit and integration tests will be run in CI.
 

docs/gitbook/dev/release-guide.md

@@ -2,33 +2,34 @@
 
 This document describes how to release Flagger.
 
-### Release
+## Release
+
+To release a new Flagger version \(e.g. `2.0.0`\) follow these steps:
 
-To release a new Flagger version (e.g. `2.0.0`) follow these steps:
 * create a branch `git checkout -b prep-2.0.0`
 * set the version in code and manifests `TAG=2.0.0 make version-set`
 * commit changes and merge PR
 * checkout master `git checkout master && git pull`
 * tag master `make release`
 
-### CI
+## CI
 
 After the tag has been pushed to GitHub, the CI release pipeline does the following:
+
 * creates a GitHub release
 * pushes the Flagger binary and change log to GitHub release
 * pushes the Flagger container image to Docker Hub
 * pushes the Helm chart to github-pages branch
 * GitHub pages publishes the new chart version on the Helm repository
 
-### Docs
+## Docs
 
 The documentation [website](https://docs.flagger.app) is built from the `docs` branch.
 
 After a Flagger release, publish the docs with:
+
 * `git checkout master && git pull`
 * `git checkout docs`
 * `git rebase master`
 * `git push origin docs`
 
-
-

docs/gitbook/dev/upgrade-guide.md

@@ -2,9 +2,10 @@
 
 This document describes how to upgrade Flagger.
 
-### Upgrade canaries v1alpha3 to v1beta1
+## Upgrade canaries v1alpha3 to v1beta1
 
 Canary CRD changes in `canaries.flagger.app/v1beta1`:
+
 * the `spec.canaryAnalysis` field has been deprecated and replaced with `spec.analysis`
 * the `spec.analysis.interval` and `spec.analysis.threshold` fields are required
 * the `status.lastAppliedSpec` and `status.lastPromotedSpec` hashing algorithm changed to `hash/fnv`
@@ -17,17 +18,17 @@ Canary CRD changes in `canaries.flagger.app/v1beta1`:
 * the `spec.service.meshName` field has been deprecated and no longer used for `provider: appmesh:v1beta2`
 
 Upgrade procedure:
+
 * install the `v1beta1` CRDs
 * update Flagger deployment
 * replace `apiVersion: flagger.app/v1alpha3` with `apiVersion: flagger.app/v1beta1` in all canary manifests
 * replace `spec.canaryAnalysis` with `spec.analysis` in all canary manifests
 * update canary manifests in cluster
 
-**Note** that after upgrading Flagger, all canaries will be triggered as the hash value used for tracking changes
-is computed differently. You can set `spec.skipAnalysis: true` in all canary manifests before upgrading Flagger,
-do the upgrade, wait for Flagger to finish the no-op promotions and finally set `skipAnalysis` to `false`.
+**Note** that after upgrading Flagger, all canaries will be triggered as the hash value used for tracking changes is computed differently. You can set `spec.skipAnalysis: true` in all canary manifests before upgrading Flagger, do the upgrade, wait for Flagger to finish the no-op promotions and finally set `skipAnalysis` to `false`.
 
 Update builtin metrics:
+
 * replace `threshold` with `thresholdRange.min` for request-success-rate
 * replace `threshold` with `thresholdRange.max` for request-duration
 
@@ -43,11 +44,9 @@ metrics:
   interval: 1m
 ```
 
-### Istio telemetry v2
+## Istio telemetry v2
 
-Istio 1.5 comes with a breaking change for Flagger uses. In Istio telemetry v2 the metric 
-`istio_request_duration_seconds_bucket` has been removed and replaced with `istio_request_duration_milliseconds_bucket`
-and this breaks the `request-duration` metric check.
+Istio 1.5 comes with a breaking change for Flagger uses. In Istio telemetry v2 the metric `istio_request_duration_seconds_bucket` has been removed and replaced with `istio_request_duration_milliseconds_bucket` and this breaks the `request-duration` metric check.
 
 If are using **Istio 1.4**, you can create a metric template using the old duration metric like this:
 
@@ -88,3 +87,4 @@ metrics:
     max: 0.500
   interval: 1m
 ```
+