We need to lock more dependencies and maintain old build images for stable branches.

Every time we make a change to gitlab-build-images, it re-builds all of our test images and publishes them for gitlab CE and EE to use in our test suite. This process inadvertently bumps the versions of yarn, node, and chrome to the latest stable version. This has caused problems in our pipelines on gitlab-ce and gitlab-ee before:

• Bumping Chrome v59 to v60 caused karma tests to fail! (gitlab-org/gitlab-ce#36517)
• Having two build images with different versions of yarn caused confusing job failures (see #12 (closed))

This problem is exacerbated on older stable branches, where we may not touch them for months at a time. The build images they are using may have leaped over several versions of these dependencies in the meantime and we end up seeing several unrelated build failures that may have been fixed in master but were never back-ported!

Yarn and Node could be locked down to a specific version if we wanted to, but they are currently not. Chrome presents a different problem:

Google has a policy of yanking old versions of Chrome from their PPA after every new release, so our attempt at locking Chrome to a particular version causes build failures (the master pipeline is broken as I write this).

Currently the fact that these builds fail is a "good" thing. It prevents the GitLab CE/EE test images from auto-updating every time we make unrelated changes (to omnibus for example). The builds fail when Chrome cannot be found and that particular build image remains at the old version until someone explicitly updates the CHROME_VERSION variable to fix it.

We need to:

• Lock yarn and node the same way we lock ruby, git, and postgresql in our build images.
• Find a way to lock Google Chrome.

We've hacked around this problem by using older images with older versions of Chrome as the basis for new images (!54 (merged)), but I think we need a more formal solution here.