ci: Deduplicate and add timing measurements

This won't affect CI performance, but should hopefully make it easier to make and measure improvements.

added 1 commit

• 81dc83ee - ci: Install `sudo` if not present

Compare with previous version

added 1 commit

• 3ec22372 - ci: Install `sudo` if not present

Compare with previous version

I had a go at testing this on my own GitLab CI runner, but i didn't get anywhere. The problem is that the main runners seem to be dedicated machines with dependencies pre-installed. My runner needs to build inside a 'docker' image, but the existing commands don't work in that case.

@samthursfield What do you mean "existing commands"? You mean the apt-get stuff?

All of the existing building commands. My first build failed due to no sudo in the container, so I added apt-get install sudo. My second build failed due to no wget in the container, and at that point I realised I'd have to manually install compiler, libraries, all PD's build dependencies in the container before anything could build.

merged

They are all quick-and-dirty commands I got from a quick-and-dirty demo that was in some part of the gitlab documentation. So if we need to de-couple things that is certainly possible.

If there is a way to script updating through vboxmanage for my VM's that's probably preferable. I'll see if there are any such scripts out there.

I realised there's an easy way (based on Albert's packaging) to pre-build a container image with PD's build-dependencies, so I can use that for testing.

In the long term I'd suggest using containers inside the VMs for the Linux builds. Mainly it's a matter of having a suitable container image, and using 'docker' instead of 'script' mode when configuring gitlab-runner. This way you can run more than one build inside a VM in parallel, and can mix and match distros and distro versions more easily. It wouldn't make anything go faster though :)