From 0e945d3bd1bcfdda13b3849aefc45b646739bd8b Mon Sep 17 00:00:00 2001
From: Hidde Beydals <hello@hidde.co>
Date: Thu, 18 Apr 2019 12:44:07 +0200
Subject: [PATCH] Give master builds their own prerelease homes

This prevents the Flux daemon from keeping track of (potentially)
hundreds of master build tags it is not making use of while keeping
them available to the public.
---
 .circleci/config.yml | 12 ++++++++----
 site/faq.md          |  8 ++++----
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index ac402dbd31..b675a0d8eb 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -16,12 +16,16 @@ jobs:
       - run: make all
 
       - deploy:
-          name: Maybe push master image
+          name: Maybe push prerelease images
           command: |
             if [ -z "${CIRCLE_TAG}" -a "${CIRCLE_BRANCH}" == "master" ]; then
-              echo "$DOCKER_REGISTRY_PASSWORD" | docker login --username "$DOCKER_REGISTRY_USER" --password-stdin 
-              docker push "docker.io/weaveworks/flux:$(docker/image-tag)"
-              docker push "docker.io/weaveworks/helm-operator:$(docker/image-tag)"
+              echo "$DOCKER_REGISTRY_PASSWORD" | docker login --username "$DOCKER_REGISTRY_USER" --password-stdin
+
+              docker tag "docker.io/weaveworks/flux:$(docker/image-tag)" "docker.io/weaveworks/flux-prerelease:$(docker/image-tag)"
+              docker push "docker.io/weaveworks/flux-prerelease:$(docker/image-tag)"
+
+              docker tag "docker.io/weaveworks/helm-operator:$(docker/image-tag)" "docker.io/weaveworks/helm-operator-prerelease:$(docker/image-tag)"
+              docker push "docker.io/weaveworks/helm-operator-prerelease:$(docker/image-tag)"
             fi
 
       - deploy:
diff --git a/site/faq.md b/site/faq.md
index 4bea052acf..e8d8248441 100644
--- a/site/faq.md
+++ b/site/faq.md
@@ -9,7 +9,7 @@ menu_order: 60
   * [How is that different from a bash script?](#how-is-that-different-from-a-bash-script)
   * [Why should I automate deployment?](#why-should-i-automate-deployment)
   * [I thought Flux was about service routing?](#i-thought-flux-was-about-service-routing)
-  * [Are there nightly builds I can run?](#are-there-nightly-builds-i-can-run)
+  * [Are there prerelease builds I can run?](#are-there-prerelease-builds-i-can-run)
 - [Technical questions](#technical-questions)
   * [Does it work only with one git repository?](#does-it-work-only-with-one-git-repository)
   * [Do I have to put my application code and config in the same git repo?](#do-i-have-to-put-my-application-code-and-config-in-the-same-git-repo)
@@ -81,12 +81,12 @@ There are some pretty good solutions for service routing:
 [Envoy](https://www.envoyproxy.io/), [Istio](https://istio.io) for
 example. We may return to the matter of staged deployments.
 
-### Are there nightly builds I can run?
+### Are there prerelease builds I can run?
 
 There are builds from CI for each merge to master branch. See
-[weaveworks/flux](https://hub.docker.com/r/weaveworks/flux/tags)
+[weaveworks/flux-prerelease](https://hub.docker.com/r/weaveworks/flux-prerelase/tags)
 and
-[weaveworks/helm-operator](https://hub.docker.com/r/weaveworks/helm-operator/tags).
+[weaveworks/helm-operator-prerelease](https://hub.docker.com/r/weaveworks/helm-operator-prerelease/tags).
 
 ## Technical questions