Signed-off-by: Lucille Hua <[email protected]>

Fixes #11

Signed-off-by: Lucille Hua <[email protected]>

Temporary fix until jetify-com/devbox#1453 is
released

### Description
macOS caching is broken. This PR fixes it. This is related to `gtar` not
having `sudo` permission, but `/nix/store` requires sudo. There are many
many related issues out there. eg.
actions/cache#749

I also switched to using DeterminateSystems nix installer. However, I
noticed that even though cache is successfully restored in the latest
round of CICD, we are still fetching the binaries from remote? (at least
based on the log lines) Why is that?

I suspect that I'm missing some sqlite data in the cached files. cc
@savil @gcurtis if any of you have insights into this.

EDIT: SOLVED. Added xdg paths in the cache and it reduces the time by
half. 🎉 🎉 🎉

closes #13

Signed-off-by: Lucille Hua <[email protected]>

Narrow the cache of xdg directory per request from @savil

Reverts #20

This results in the `~/.cache` directory gets created under `root`
instead of `runner`. Reverting fix this problem.

Verified the fix with
#21

### What
This PR tries to reduce side effects by:
- Restores the `tar` command to its original state
- Narrow the ~/.cache directory to just nix and devbox

### Why
We are using `chmod u+s "$(command -v tar)"` to setuid on tar (This is
needed because we are caching `/nix/` and other directories outside of
`~`, which is owned by `root`)

This has a problem where it changes the parent directory of
`~/.cache/nix` to be owned by `root` instead of `runner`.

I thought #22
had fixed it, but we ran into similar issues when we use a go cache on
top of the devbox cache.

### Caveat
Cache enabled on self hosted Linux may stop working

We have some problems in our custom runner with this action so I've
tried it with skipping the installation via the included action and it
works in our runners (we do not use the GitHub provided ones, we are
using custom runners).

In case you are wondering which action we are using, we use:
`cachix/install-nix-action@v23` - I guess it has something to do with
the usage of `sudo` in the other action but I'm not 100% sure on that.
I'm also not sure about the differences between these two actions so
I've opted for the possibility to skip the installation rather than
changing the action as I guess you've put a lot of thought into which
action to use.

Edit: I need to correct myself, it's not because of `sudo` but because
of `systemd`. I tried to run the action without `systemd` by passing in
`init: none` and `planner: linux-multi` but I got other errors. So I
would prefer to be able to just skip the installation and use my own / a
different action to install `nix`.

### What
Instead of letting `action/cache` do the restoring and saving cache for
us, we choose when to restore and when to save cache.

In this case, we will be saving cache immediately after the devbox
package installation, instead of waiting for the action post run. This
way, the `tar` sudo permission stays intact until the cache is saved.

More specifically, `action/cache/save` runs before the last step of
restoring `tar` to its original permission (as oppose to after)