clarify how to setup a staging env and why we would (and why not) authored by anarcat's avatar anarcat
Stumbled upon this while trying to figure out whether I need staging
for spec.tpo and how I would go around doing it (#41348).
...@@ -131,7 +131,7 @@ auto-stopped (deleted) after 1 week without being updated. ...@@ -131,7 +131,7 @@ auto-stopped (deleted) after 1 week without being updated.
## Working with a staging environment ## Working with a staging environment
Our web projects have a specific staging area that is separate from Some web projects have a specific staging area that is separate from
GitLab Pages and `review.torproject.net`. Those sites are deployed as GitLab Pages and `review.torproject.net`. Those sites are deployed as
subdomains of `*.staging.torproject.net` on the static mirror system. subdomains of `*.staging.torproject.net` on the static mirror system.
For example, the staging URL for `blog.torproject.org` is For example, the staging URL for `blog.torproject.org` is
...@@ -140,14 +140,24 @@ For example, the staging URL for `blog.torproject.org` is ...@@ -140,14 +140,24 @@ For example, the staging URL for `blog.torproject.org` is
Staging environments can be useful in various scenarios, such as when Staging environments can be useful in various scenarios, such as when
the build job for the production environment is different than the one the build job for the production environment is different than the one
for Review Apps, so a staging URL is useful to be able to preview a full for Review Apps, so a staging URL is useful to be able to preview a full
build before being deployed to production. build before being deployed to production. This is especially
important for large websites like `www.torproject.org` and the
blog which use the "partial build" feature in Lego to speed up the
review stage. In that case, the staging site is a full build that
takes longer, but then allows prod to be launched quicker, after a
review of the full build.
For other sites, the above and automatic `review.torproject.net`
configuration is probably sufficient.
To enable a staging environment, first a DNS entry must be created To enable a staging environment, first a DNS entry must be created
under `*.staging.torproject.net` and pointed to under `*.staging.torproject.net` and pointed to
`static.torproject.org`. Then some configuration changes are needed in `static.torproject.org`. Then some configuration changes are needed in
Puppet so the necessary symlinks and vhosts are created on the static Puppet so the necessary symlinks and vhosts are created on the static
web mirrors. These steps must be done by TPA, so please web mirrors. These steps must be done by TPA, so please [open a
[open a ticket](https://gitlab.torproject.org/tpo/tpa/team/-/issues/new). ticket](https://gitlab.torproject.org/tpo/tpa/team/-/issues/new). For TPA, look at commits
262f3dc19c55ba547104add007602cca52444ffc and
118a833ca4da8ff3c7588014367363e1a97d5e52 for examples on how to do this.
Lastly, a `STAGING_URL` variable must be added to `.gitlab-ci.yml` with Lastly, a `STAGING_URL` variable must be added to `.gitlab-ci.yml` with
the staging domain name (eg. `blog.staging.torproject.org`) as its the staging domain name (eg. `blog.staging.torproject.org`) as its
... ...
......