GitLab

Most of these comments are not accurate anymore, anyway.

Otherwise we should assume the website is under development and only
deploy to review.tpn and staging, if STAGING_URL exists.

This also add some info messages about which ssh private key is picked
up, but in short what happened here is that because I added the
"tor-www@" prefix to the environment URLs, those wouldn't match the
grep command on review.tpn anymore, and since the project's
STATIC_GITLAB_SHIM_SSH_PRIVATE_KEY is scoped to the production
environment only, CI running on branches would end up with an null ssh
private key. If this happens again hopefully the build log will contain
a bit more useful info.

Run check_l10n_freshness for merge requests

Closes #12

See merge request !29

Closes: #12

The environment should remain permanently.

the original SITE_URL isn't accessible here

Same private key setup as for review.tpn, placing it at the GitLab gorup
level to avoid the need to add it to every individual project.

Recent releases of some Lektor dependencies have started causing build
failures, specifically Werkzeug 2.1.0 and Jinja2 3.1.1.

This adjusts the build process to installed dependencies using hashed
pinning. On top of locking down our Lektor build stack, this avoids
the need to trust pip deploying arbitrary code every CI build...

for deploy-staging jobs, part of tpo/web/team#34

This reverts commit f3942dd4.

With GitLab 14.8 this hopefully shouldn't be needed anymore.

Avoid keeping stale review apps in the review.tpn static component
because it turns out that the more content we have in there, the longer
updates and deployments can take. See #8

This might help fix #8

Project-level timeouts can vary according to build times but deployments
are not supposed to vary much from project to project, so use 1h for all
jobs interacting with static-gitlab-shim.

Related: #8

We witnessed multiple deploy-l10n-staging jobs running in parallel which
shouldn't be happening if resource_group parameter was indeed copied by
extending deploy-review, so we're copying it here to see if it helps.

Thos do not need to be kept around on the server as they are deployed
immediately and updated often.

There's probably no benefit here of using different caches on every
branch, so just remove cache:key. Caches are NOT shared between
different projects.

And for check_l10n_freshness, assume that the apt cache is already
sufficiently recent so skip uploading it back to GitLab to relieve
some pressure.

I think the buildstate files created there are useless without
preexisting build artifacts, so unless we want to cache build artifacts,
which I don't think we do, we can save some space by skipping it. This
directory is also where Lektor installs plugin packages, but again I
don't think there are major benefits to caching these, since they
essentially are copies of files already present in the repository.

renamed check_l10n_freshness

This happened on projects that did not scope STATIC_GITLAB_SHIM_SSH_PRIVATE_KEY
to the production environment, so that sshkey was overriding the job-level
STATIC_GITLAB_SHIM_SSH_PRIVATE_KEY variable and causing an unwanted
deployment to production.

The solution was to change the scope for STATIC_GITLAB_SHIM_SSH_PRIVATE_KEY
to the production environment instead of All (the default), which was
done for all projects which use the ci-templates.

However to make things extra-safe, instead of playing with variable
overrides, ensure that if the environment URL contains "review.tpn",
always replace the original STATIC_GITLAB_SHIM_SSH_PRIVATE_KEY with
REVIEW_STATIC_GITLAB_SHIM_SSH_PRIVATE_KEY altogether.

This job seems to be using the wrong ssh key and is still causing
the deployment to happen on production...

This makes sure that old versions of packages don't stay in the cache
forever.

This removes /etc/apt/apt.conf.d/docker-clean which was cleaning up
apt/dpkg completely and preventing any kind of actual caching. Also this
toggles Binary::apt::APT::Keep-Downloaded-Packages which is needed
otherwise the .debs are not kept.

These keys should have been merged from the deploy-review job that we
extend, but it doesn't appear to be working as expected, and is
currently instead deploying to prod... yikes!

At least the fix is simple, just copy the key/value pairs from the
source job.

Makes more sense to group the jobs in this fashion, so that the deploy
stuff is all grouped together. Also less likely to break possible
expectations of 'lektor.yml' not deploying anything, just providing
build and test jobs.

With the previous setup there would be duplicated build jobs.