Deployment and CI scripts #25
Conversation
|
I'll take a look tn |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Since we're using command-restricted SSH keys, we can only run one command per key. Instead of having to manage 4 separate keys to run each script, we can just do, e.g., "ssh vulcan build" to execute build.sh. The authorized_keys file will have command=".../launch.sh".
- Changes into ~/webring first - Passes arguments along to script being invoked
|
LGTM! |
There was a problem hiding this comment.
Overall looks pretty good. The biggest thing I recommend is moving home manager into the flake itself, and using Nix's syntax for building from a remote checkout to avoid needing to manage a cloned directory yourself. It would cut down on a lot of the work done in the CI scripts.
|
|
||
| # Set up the testing directory in tmpfs | ||
|
|
||
| CI_PATH=/dev/shm/webring-ci |
There was a problem hiding this comment.
Technically it wouldn't be taking up storage, and instead taking up RAM.
There was a problem hiding this comment.
Strictly speaking, you can just do nix build github:purduehackers/webring/<HASH> instead of checking out anything. This will fetch the commit directly from GitHub and build it, instead of needing to manage the worktree yourself.
This would also negate the cleanup.
There was a problem hiding this comment.
Come to think of it, would it be possible to do this using the git repo's actual origin instead of hardcoding ours? It would be nice to not have to change it if the repo moves or someone forks the project.
There was a problem hiding this comment.
If we use nix build github:..., we'd only need that one command, not a whole script, right? If that's the case, we can just put that command directly in the GH Actions workflow and get the repository URL from the runner's environment.
There was a problem hiding this comment.
And if we do that, the repo origin would be hardcoded in the github action rather than the repo itself...
There was a problem hiding this comment.
No, it could use the ${{ github.repositoryUrl }} variable.
There was a problem hiding this comment.
Technically it could use git remote get-url origin. Its just that the nix build command doesn't seem to like taking in a link. I could probably figure that out.
There was a problem hiding this comment.
If we get the origin URL from a Git repository on Vulcan, that involves statefulness. The repository needs to exist, have an up-to-date origin URL, etc.
I think it would be better (as long as we don't need a full script) to just inject the URL from the GitHub Actions workflow. That way deploying is essentially stateless (except for the SSH key setup), which reduces the number of places in which we have to maintain things.
If we do need a script, then go ahead and use the origin URL from the repo on Vulcan, since it'll have to exist already for the script to be there. This is just for if we don't need to have a script, and the nix build ... command is enough.
ci/vulcan/home.nix
Outdated
| }; | ||
|
|
||
| Service = { | ||
| ExecStart = "${pkgs.bubblewrap}/bin/bwrap --bind /home/ring/webring-data /webring --ro-bind /nix/store /nix/store --ro-bind /etc /etc --tmpfs /tmp --unshare-all --share-net --new-session --chdir /webring --uid 256 --gid 512 --die-with-parent ${webring}/bin/ph-webring"; |
There was a problem hiding this comment.
Instead of using bwrap inline here, it may be worthwhile to instead use the systemd unit file policies to represent a similar set of permissions. This would reduce the complexity of the command invocation.
The options you need are mainly in the Sandboxing section of systemd.exec
I will grant, I don't know if user units have restrictions on it, but I don't think it does in this case (outside of not being able to grant write access to paths it can't write to, of course.)
There was a problem hiding this comment.
There seem to be a lot of options in there and they're all allow by default. It looks like it would be a lot less config to keep the bwrap command since it's deny by default.
There was a problem hiding this comment.
See previous comment about using nix commands with a github:... reference. If home manager is moved to the flake, this could be reduced down to home-manager switch --flake github:purduehackers/webring/<HASH>
Add a bunch of shell scripts and nix files to enable deployment and integration testing on Vulcan through Github's CI