Skip to content

Commit 101ba1b

Browse files
coury-clarkcoury-clark
authored
remove customer-replica references from this repo (#902)
1 parent 4970a06 commit 101ba1b

File tree

2 files changed

+8
-144
lines changed

2 files changed

+8
-144
lines changed

‎RELEASING.md‎

Lines changed: 8 additions & 137 deletions
Original file line numberDiff line numberDiff line change
@@ -3,14 +3,17 @@
33
**This is the guide for releasing the [Pure-Docker Sourcegraph deployment reference](./pure-docker/README.md).**
44
The docker-compose release is done entirely via the [Sourcegraph release tool](https://about.sourcegraph.com/handbook/engineering/distribution/tools/release).
55

6-
## Branching/tagging scheme
6+
## Customer Replica
7+
8+
We maintain a copy of pure-docker in a separate [repo](https://github.com/sourcegraph/deploy-sourcegraph-docker-customer-replica-1) for a [customer](https://github.com/sourcegraph/accounts/issues/565). In the past
9+
this was maintained in this repo as a separate series of branches that were suffixed with -customer-replica. This was deprecated in favor of the separate repo after 4.4.1. The repo is included in our release automation so no additional manual steps are required after 4.4.1. This note is just sharing context for future releases and for anyone referencing -customer-replica branches.
710

8-
Just like deploy-sourcegraph, we use version branches and version tags. We _additionally_ have a second set which is customer-replication branches and version tags:
11+
## Branching/tagging scheme
912

10-
- Tag examples: `v3.8.2`, `v3.9.2`, `customer-replica-v3.8.2`, `customer-replica-v3.9.2-2`
11-
- Branch examples: `3.8`, `3.9`, `3.8-customer-replica`, `3.9-customer-replica`
13+
Just like deploy-sourcegraph, we use version branches and version tags.
1214

13-
The customer replica branches are distinct living branches which have diffs we maintain for replicating some customers using the pure-docker deployment model described in the README.md of this repository (e.g. the customers' different Postgres version, changes to the `prometheus_targets.yml`, and more.) We test, tag, and release these `$VERSION-customer-replica` branches as `customer-replica-$VERSION` to produce the final diffs we send to customers running a pure-docker deployment on e.g. in the [pure docker upgrade guide](https://docs.sourcegraph.com/admin/updates/pure_docker).
15+
- Tag examples: `v3.8.2`, `v3.9.2`
16+
- Branch examples: `3.8`, `3.9`
1417

1518
## Releasing a new version
1619

@@ -66,135 +69,3 @@ git push origin v3.9.2
6669
For pure-docker, we provide customers with an exact diff of changes to make. They do not run our deploy.sh scripts directly, instead they copy them or adapt them to their own deployment environment entirely. This means we must carefully communicate each change that is made.
6770

6871
To reduce the chance for errors, we send an exact diff of changes. This diff needs to be as minimal and concise as possible, and e.g. not include changes to unrelated files like `.prettierignore` or `docker-compose/` to avoid any confusion. See https://docs.sourcegraph.com/admin/updates/pure_docker for examples of what these diffs look like.
69-
70-
### Major/Minor release
71-
72-
Pretend `3.8` was the last version of pure-docker release (look for the latest `n.n-customer-replica` branch), and that `3.9` is the version we want to release. Then:
73-
74-
```sh
75-
# Checkout the current pure-docker release branch
76-
git checkout 3.8-customer-replica
77-
78-
# Create the new pure-docker release branch
79-
git checkout -B 3.9-customer-replica
80-
81-
# Merge the publish-3.9.0 branch, which will have been created by the release tool, into the pure-docker release branch. Default to taking the remote changes. Note that "theirs" is a Git term, not a placeholder.
82-
git merge publish-3.9.0 -X theirs
83-
84-
# Reset to previous commit so we can manually inspect ALL changes - we want to create multiple commits instead of keeping a single merge commit
85-
git reset HEAD~
86-
87-
# Show which files may have been deleted, etc.
88-
git status
89-
```
90-
91-
While committing in next steps, you will run into two merge conflicts:
92-
93-
- Do not commit `deploy-caddy.sh` or changes related to it, as `deploy-apache.sh` is used here.
94-
- The `.prettierignore` should contain the following lines:
95-
96-
```
97-
.github/
98-
*.md
99-
rootfs/etc/docker/daemon.json
100-
```
101-
102-
At this point you should evaluate the `git status` output as well as all the changes in your working git directory. You need to ensure the following happens:
103-
104-
1. Files that were shown as deleted in the `git status` output get deleted in the relevant commit.
105-
2. Create **one** commit with changes _unrelated to the upgrade_, i.e. include ALL changes that are not directly related to upgrading:
106-
- `git commit -m 'merge 3.9 (changes unrelated to upgrade)'`
107-
3. Create **one** commit with the changes _customers need to apply in order to ugprade_, i.e. the image tag changes, adding/removing any new services, updating env vars, but no unrelated changes.
108-
- Do not include `docker-compose/` changes in this commit, those are irrelevant to pure-docker users.
109-
- Double check `pure-docker/deploy-pgsql.sh` file and make sure it has the correct image sha. It should look something like `index.docker.io/sourcegraph/postgres-12.6-alpine:3.36.3@sha256:<hash>`
110-
- `git commit -m 'upgrade to v3.9.0'`
111-
4. Push the changes
112-
```shell
113-
git push --set-upstream origin 3.9-customer-replica
114-
```
115-
116-
Check buildkite for the branch after pushing it, e.g. at https://github.com/sourcegraph/deploy-sourcegraph-docker/commits/3.19-customer-replica
117-
118-
This will take about ~10 minutes to run. Refer to the [testing documentation](TESTING.md) if you run into issues / need more instructions.
119-
120-
Once you see `ALL TESTS PASSED`, tag the release:
121-
122-
```sh
123-
git tag customer-replica-v3.9.0
124-
git push origin customer-replica-v3.9.0
125-
```
126-
127-
Write an entry for https://docs.sourcegraph.com/admin/updates/pure_docker which includes:
128-
129-
- A link to your `upgrade to v3.9.0` commit describing the exact changes needed to be made.
130-
- Any specific manual migrations, including potential `chown` commands that may be needed (if any new service is introduced, etc.)
131-
- Look at https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+is%3Aopen+pure-docker to see if there are any open PRs that might need to be included.
132-
133-
### Patch release
134-
135-
Pretend `3.8` was the last version of pure-docker release (look for the latest `n.n-customer-replica` branch), and that `3.8.1` is the version we want to release. Then:
136-
137-
```sh
138-
# Checkout the current pure-docker release branch
139-
git checkout 3.8-customer-replica
140-
141-
# Create the new pure-docker release branch
142-
git checkout -B 3.8.1-customer-replica
143-
144-
# Merge the publish-3.8.1 branch, which will have been created by the release tool, into the pure-docker release branch. Default to taking the remote changes.
145-
git merge publish-3.8.1 -X theirs
146-
147-
# Reset to previous commit so we can manually inspect ALL changes - we want to create multiple commits instead of keeping a single merge commit
148-
git reset HEAD~
149-
150-
# Show which files may have been deleted, etc.
151-
git status
152-
```
153-
154-
While committing in next steps, you will run into two merge conflicts:
155-
156-
- Do not commit `deploy-caddy.sh` or changes related to it, as `deploy-apache.sh` is used here.
157-
- The `.prettierignore` should contain the following lines:
158-
159-
```
160-
.github/
161-
*.md
162-
rootfs/etc/docker/daemon.json
163-
```
164-
165-
At this point you should evaluate the `git status` output as well as all the changes in your working git directory. You need to ensure the following happens:
166-
167-
1. Files that were shown as deleted in the `git status` output get deleted in the relevant commit.
168-
2. Create **one** commit with changes _unrelated to the upgrade_, i.e. include ALL changes that are not directly related to upgrading:
169-
- `git commit -m 'merge 3.8.1 (changes unrelated to upgrade)'`
170-
3. Create **one** commit with the changes _customers need to apply in order to ugprade_, i.e. the image tag changes, adding/removing any new services, updating env vars, but no unrelated changes.
171-
- Do not include `docker-compose/` changes in this commit, those are irrelevant to pure-docker users.
172-
- Double check `pure-docker/deploy-pgsql.sh` file and make sure it has the correct image sha. It should look something like `index.docker.io/sourcegraph/postgres-12.6-alpine:3.36.3@sha256:<hash>`
173-
- `git commit -m 'upgrade to v3.8.1'`
174-
4. Push the changes to github
175-
```shell
176-
git push --set-upstream origin 3.8.1-customer-replica
177-
```
178-
179-
Open a Pull Request against `3.8-customer-replica` (base branch)
180-
181-
Check buildkite for the branch after pushing it, e.g. at https://github.com/sourcegraph/deploy-sourcegraph-docker/commits/3.19-customer-replica
182-
183-
This will take about ~10 minutes to run. Refer to the [testing documentation](TESTING.md) if you run into issues / need more instructions.
184-
185-
Once you see `ALL TESTS PASSED`, merge the Pull Request and tag a new release
186-
187-
```sh
188-
git checkout 3.8-customer-replica
189-
git pull
190-
git tag customer-replica-v3.8.1
191-
git push origin customer-replica-v3.8.1
192-
```
193-
194-
Write an entry for https://docs.sourcegraph.com/admin/updates/pure_docker which includes:
195-
196-
- A link to your `upgrade to v3.8.1` commit describing the exact changes needed to be made.
197-
- Any specific manual migrations, including potential `chown` commands that may be needed (if any new service is introduced, etc.)
198-
- Look at https://github.com/sourcegraph/sourcegraph/pulls?q=is%3Apr+is%3Aopen+pure-docker to see if there are any open PRs that might need to be included.
199-
200-
Contact https://app.hubspot.com/contacts/2762526/company/407948923/ over Slack and inform them the update is available, providing a link to the diff and other relevant details like the blog post link.

‎test/smoke-test.sh‎

Lines changed: 0 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -7,14 +7,7 @@ deploy_sourcegraph() {
77
if [[ "$TEST_TYPE" == "pure-docker-test" ]]; then
88
./test/volume-config.sh
99
timeout 600s ./pure-docker/deploy.sh
10-
11-
if [[ "$GIT_BRANCH" == *"customer-replica"* ]]; then
12-
# Expected number of containers on e.g. 3.18-customer-replica branch.
13-
expect_containers="61"
14-
else
15-
# Expected number of containers on `master` branch.
1610
expect_containers="26"
17-
fi
1811
elif [[ "$TEST_TYPE" == "docker-compose-test" ]]; then
1912
docker-compose --file docker-compose/docker-compose.yaml up -d -t 600
2013
expect_containers="27"

0 commit comments

Comments
 (0)