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,36 +2,35 @@
 
 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
+
+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/fluxcd/flagger) on GitHub.
 
 Create a dir inside your `GOPATH`:
 
 ```bash
-mkdir -p $GOPATH/src/github.com/weaveworks
+mkdir -p $GOPATH/src/github.com/fluxcd
 ```
 
 Clone your fork:
 
 ```bash
-cd $GOPATH/src/github.com/weaveworks
+cd $GOPATH/src/github.com/fluxcd
 git clone https://github.com/YOUR_USERNAME/flagger
 cd flagger
 ```
@@ -46,31 +45,42 @@ Sync your fork regularly to keep it up-to-date with upstream:
 
 ```bash
 git fetch upstream
-git checkout master
-git merge upstream/master
+git checkout main
+git merge upstream/main
 ```
 
-### Build
+## Build
 
 Download Go modules:
 
 ```bash
 go mod download
 ```
 
-Build Flagger binary and container image:
+Build Flagger binary:
 
 ```bash
 make build
 ```
 
-Build load tester binary and container image:
+Build load tester binary:
 
 ```bash
 make loadtester-build
 ```
 
-### Code changes
+## Code changes
+
+We require all commits to be signed. By signing off with your signature, you
+certify that you wrote the patch or otherwise have the right to contribute the
+material by the rules of the [DCO](https://raw.githubusercontent.com/fluxcd/flagger/main/DCO).
+
+If your `user.name` and `user.email` are configured in your Git config,
+you can sign your commit automatically with:
+
+```bash
+git commit -s
+```
 
 Before submitting a PR, make sure your changes are covered by unit tests.
 
@@ -98,7 +108,7 @@ Run unit tests:
 make test
 ```
 
-### API changes
+## API changes
 
 If you made changes to `pkg/apis` regenerate the Kubernetes client sets with:
 
@@ -114,10 +124,9 @@ 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:
 
@@ -150,7 +159,7 @@ Another option to manually test your changes is to build and push the image to y
 
 ```bash
 make build
-docker tag weaveworks/flagger:latest <YOUR-DOCKERHUB-USERNAME>/flagger:<YOUR-TAG>
+docker build -t <YOUR-DOCKERHUB-USERNAME>/flagger:<YOUR-TAG> .
 docker push <YOUR-DOCKERHUB-USERNAME>/flagger:<YOUR-TAG>
 ```
 
@@ -163,7 +172,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).
 
@@ -173,39 +182,23 @@ Create a Kind cluster:
 kind create cluster
 ```
 
-Install a service mesh and/or an ingress controller in Kind.
-
-Linkerd example:
-
-```bash
-linkerd install | kubectl apply -f -
-linkerd check
-```
-
 Build Flagger container image and load it on the cluster:
 
 ```bash
 make build
-docker tag weaveworks/flagger:latest test/flagger:latest
+docker build -t test/flagger:latest .
 kind load docker-image test/flagger:latest
 ```
 
-Install Flagger on the cluster and set the test image:
-
-```bash
-kubectl apply -k ./kustomize/linkerd
-kubectl -n linkerd set image deployment/flagger flagger=test/flagger:latest
-kubectl -n linkerd rollout status deployment/flagger
-```
 
-Run the Linkerd e2e tests:
+Run the Istio e2e tests:
 
 ```bash
-./test/e2e-linkerd-tests.sh
+./test/istio/run.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).
+chose one that matches your changes from this [list](https://github.com/fluxcd/flagger/tree/main/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`
 
-
-