wpt.fyi

wpt.fyi copied to clipboard

After https://github.com/web-platform-tests/wpt.fyi/pull/2787 I updated the repo and ran ./util/docker-dev/run.sh, but found (using wptd_exec_it node --version) that the Node.js version was still 10.

It looks like the docker pull webplatformtests/wpt.fyi:latest step is only in the README, and never checked automatically. This means that one can try to deploy using a stale version of the Docker image without noticing. If there's a problem with the deployment later, it would be very difficult to trace down the cause of this.

@KyleJu do you think we could check that the image is up to date in ./util/docker-dev/run.sh?

Looking at the deployment documentation, the container image is being rebuilt every time we deploy. IIUC, this only concerns local builds.

wpt.fyi:latest container image is built both on demand and weekly, where on demand means whenever there is update on the configs. So I think it is more likely to test a local build using outdated image:

• If when we change the configs locally, we should rebuild the image locally, because webplatformtests/wpt.fyi:latest is also outdated in that case
• If not, we should just run docker pull webplatformtests/wpt.fyi:latest every time before ./util/docker-dev/run.sh.

The image is also being rebuilt for staging instance, if there are changes. I think it is safe not to check as long as we follow the steps but I am not against adding a check. WDYT?

Do you mean that it doesn't matter what version of go and node I have locally (or in a local container) when deploying, that nothing other than gcloud app deploy needs to be done locally and everything else will happen in the cloud deploy? If so, then my main concern doesn't exist.

The problem I have is that even though I followed https://github.com/web-platform-tests/wpt.fyi#setting-up-your-environment once, every time after that I just found ./util/docker-dev/run.sh in my shell history and ran that again. Unless something breaks, I'd never notice that the container is old.

What do you think about doing docker pull in ./util/docker-dev/run.sh, with a --no-update or something to prevent it? Would that affect your workflow in some way?