Browse Source

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.
Hidde Beydals 4 months ago
parent
commit
c88d1a16fe
2 changed files with 12 additions and 8 deletions
  1. 8
    4
      .circleci/config.yml
  2. 4
    4
      site/faq.md

+ 8
- 4
.circleci/config.yml View File

@@ -16,12 +16,16 @@ jobs:
16 16
       - run: make all
17 17
 
18 18
       - deploy:
19
-          name: Maybe push master image
19
+          name: Maybe push prerelease images
20 20
           command: |
21 21
             if [ -z "${CIRCLE_TAG}" -a "${CIRCLE_BRANCH}" == "master" ]; then
22
-              echo "$DOCKER_REGISTRY_PASSWORD" | docker login --username "$DOCKER_REGISTRY_USER" --password-stdin 
23
-              docker push "docker.io/weaveworks/flux:$(docker/image-tag)"
24
-              docker push "docker.io/weaveworks/helm-operator:$(docker/image-tag)"
22
+              echo "$DOCKER_REGISTRY_PASSWORD" | docker login --username "$DOCKER_REGISTRY_USER" --password-stdin
23
+
24
+              docker tag "docker.io/weaveworks/flux:$(docker/image-tag)" "docker.io/weaveworks/flux-prerelease:$(docker/image-tag)"
25
+              docker push "docker.io/weaveworks/flux-prerelease:$(docker/image-tag)"
26
+
27
+              docker tag "docker.io/weaveworks/helm-operator:$(docker/image-tag)" "docker.io/weaveworks/helm-operator-prerelease:$(docker/image-tag)"
28
+              docker push "docker.io/weaveworks/helm-operator-prerelease:$(docker/image-tag)"
25 29
             fi
26 30
 
27 31
       - deploy:

+ 4
- 4
site/faq.md View File

@@ -9,7 +9,7 @@ menu_order: 60
9 9
   * [How is that different from a bash script?](#how-is-that-different-from-a-bash-script)
10 10
   * [Why should I automate deployment?](#why-should-i-automate-deployment)
11 11
   * [I thought Flux was about service routing?](#i-thought-flux-was-about-service-routing)
12
-  * [Are there nightly builds I can run?](#are-there-nightly-builds-i-can-run)
12
+  * [Are there prerelease builds I can run?](#are-there-prerelease-builds-i-can-run)
13 13
 - [Technical questions](#technical-questions)
14 14
   * [Does it work only with one git repository?](#does-it-work-only-with-one-git-repository)
15 15
   * [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:
81 81
 [Envoy](https://www.envoyproxy.io/), [Istio](https://istio.io) for
82 82
 example. We may return to the matter of staged deployments.
83 83
 
84
-### Are there nightly builds I can run?
84
+### Are there prerelease builds I can run?
85 85
 
86 86
 There are builds from CI for each merge to master branch. See
87
-[weaveworks/flux](https://hub.docker.com/r/weaveworks/flux/tags)
87
+[weaveworks/flux-prerelease](https://hub.docker.com/r/weaveworks/flux-prerelease/tags)
88 88
 and
89
-[weaveworks/helm-operator](https://hub.docker.com/r/weaveworks/helm-operator/tags).
89
+[weaveworks/helm-operator-prerelease](https://hub.docker.com/r/weaveworks/helm-operator-prerelease/tags).
90 90
 
91 91
 ## Technical questions
92 92
 

Loading…
Cancel
Save