Align Dockerfile to with latest Vapor template

[finestructure]

This should improve a couple of things:

• running as vapor user inside the container
• avoid copying all Swift stdlib libraries (by linking with static Swift stdlib)
• keep resources and other deployed directory content read-only

[finestructure]

I'll deploy from the branch to staging to test this.

[finestructure]

curl link error needs fixing: https://gitlab.com/finestructure/swiftpackageindex/-/jobs/3049645579

[finestructure]

Successfully deployed 87d39f7df910c1bce39766984eb80253d0e9bea1 to staging

• [x] tag spi-base
• [x] update spi-base reference

[finestructure]

That's better, got ll and colour etc:

[finestructure]

Ouch, I've just realised that changing the user will cause problems with the /checkouts content:

[daveverwer]

The easiest way might be to remove all checkouts and let them get re-cloned.

[finestructure]

That's one option but it comes with trade-offs:

• even then we need to test/make sure the top level directory permissions are correct
• we wouldn't be able to migrate this automatically, i.e. we'd need to yank the existing volume out from under the analysis (after manually stopping it)
• every node in prod has its own volume (they're host-bound), so we'd have to do this four times in total (dev + 3 x prod)

[finestructure]

I've looked into this some more. A promising approach was to

• stop the app_analyze service
• on the host, cd into the volume directory and run chown -R go+w github.com-*
• deploy the updated service

This should then allow the new vapor:vapor process to write in the updated directories, changing their ownership.

I was halfway through testing that on dev when I realised that this would only work for existing github.com-* directories. I.e. new packages wouldn't be analysed.

I don't think making the parent directory go+w is an option, because it's not "inside" the volume (I think). Or at least I wouldn't want to rely on those permissions to be reflected inside the container. I think the only way to make that work reliably would be to change analysis to act not on /checkouts directly but introduce an intermediary top level directory, /checkouts/github/ inside which the GH checkouts live. That way this directory could be given the proper permissions.

I'm not going to attempt any of this for the moment. That feels like too much fiddling for too little gain. It would be nice to have the jobs run as vapor:vapor but I don't think it's critical.

I'll update the Dockerfile to make the other alignment (static linking) and comment out the user setup with a link to this comment.