| 2 Jul 2023 |
 Jonas Chevalier | thanks to all the people that are contributing on the open collective | 17:46:47 |
| 3 Jul 2023 |
|  Nate joined the room. | 18:02:23 |
 Danila Danko | Hi! I made a GitHub action that caches only nix store paths that were accessed during a run. https://github.com/deemp/cache-nix-too . | 18:53:22 |
| Danila Danko | I'd like to transfer it to nix-community. However, there is an issue https://github.com/deemp/cache-nix-too/issues/1
On macOS runners, restored and newly created cache size bounces. First time, new cache is large. In the next run, created cache is small. Then, the cycle repeats. I have no expertise to explain this behavior so I decided to write here before a transfer.
Any ideas why does it happen? | 18:57:56 |
 Ilan Joselevich (Kranzes) | In reply to @br4ch1st0chr0n3:matrix.org
Hi! I made a GitHub action that caches only nix store paths that were accessed during a run. https://github.com/deemp/cache-nix-too . https://github.com/DeterminateSystems/magic-nix-cache | 18:58:33 |
| Ilan Joselevich (Kranzes) | is this something like this? | 18:58:36 |
| Danila Danko | * Hi! I made a GitHub action that caches into GitHub cache nix store paths that were accessed during a run. https://github.com/deemp/cache-nix-too . | 19:00:05 |
| Danila Danko | In reply to @kranzes:matrix.org
https://github.com/DeterminateSystems/magic-nix-cache No, I wrote here https://github.com/DeterminateSystems/magic-nix-cache-action/issues/16 what I didn't like about their approach. TL;DR rate limit | 19:00:53 |
| Danila Danko | In reply to @kranzes:matrix.org
https://github.com/DeterminateSystems/magic-nix-cache * No, I wrote here https://github.com/DeterminateSystems/magic-nix-cache-action/issues/16 what I didn't like about their approach. TL;DR rate limit and Caches littered with entries | 19:01:32 |
| Danila Danko | * No, I wrote here https://github.com/DeterminateSystems/magic-nix-cache-action/issues/16 what I didn't like about their approach. TL;DR rate limit and GitHub Actions Caches littered with entries | 19:02:48 |
| Danila Danko | In this action, I just nix copy from a cache, run other steps, at the end look what paths were accessed (by atime) and nix copy them to cache. Finally, I save a single cache entry. | 19:04:50 |
| Danila Danko | Somehow on macOS the assumption that a job always accesses approximately the same set of paths doesn't work | 19:08:55 |
| Danila Danko | * Somehow, on macOS runners, the assumption that a job always accesses approximately the same set of paths doesn't work | 19:09:13 |
| Danila Danko | * Somehow, on macOS runners, the assumption that a job always accesses approximately the same set of paths doesn't work. | 19:09:33 |
| Danila Danko | Moreover, I don't know how to enforce such access behavior. | 19:11:17 |
| Danila Danko | * Moreover, I don't know how to enforce such access behavior because I don't really know how Nix works. | 19:11:47 |
| Danila Danko | * Moreover, I don't know how to enforce such access behavior because I don't really know how nix package manager internally works on macOS. | 19:12:23 |
| Danila Danko | * I'd like to transfer it to nix-community. It works OK on Linux. However, there is an issue https://github.com/deemp/cache-nix-too/issues/1 with macOS runners.
On macOS runners, a restored and newly created cache size bounces. First time, a new cache is large. In the next run, a created cache is small. Then, the cycle repeats, i.e. the newly created cache is big. I have no expertise to explain this behavior so I decided to ask here.
Any ideas why does it happen? | 19:13:57 |
| Danila Danko | * I'd like to transfer it to nix-community. It works OK on Linux. However, there is an issue https://github.com/deemp/cache-nix-too/issues/1 with macOS runners.
In this action, I just nix copy from a cache, run other steps, at the end look what paths were accessed (by atime) and nix copy them to cache. Finally, I save a single cache entry.
On macOS runners, a restored and newly created cache size bounces. First time, a new cache is large. In the next run, a created cache is small. Then, the cycle repeats, i.e. the newly created cache is big. I have no expertise to explain this behavior so I decided to ask here.
Any ideas why does it happen?
| 19:14:33 |
| Danila Danko | * I'd like to transfer it to nix-community. It works OK on Linux. However, there is an issue https://github.com/deemp/cache-nix-too/issues/1 with macOS runners.
In this action, I just nix copy from a cache, run other steps, at the end look what paths were accessed (by atime) and nix copy them to cache. Finally, I save a single cache entry.
On macOS runners, a restored and saved cache size bounces. First time, a saved cache is large. In the next run, a saved cache is small. Then, the cycle repeats. I have no expertise to explain this behavior so I decided to ask here.
Any ideas why does it happen?
| 19:17:13 |
| Danila Danko | * Moreover, I don't know how to enforce such access behavior because I don't know how nix package manager internally works on macOS. | 19:17:37 |
|  hanleym joined the room. | 19:24:28 |
| Danila Danko | * Moreover, I don't know how to enforce such an access behavior because I don't know how nix package manager internally works on macOS. | 19:25:23 |
| 4 Jul 2023 |
| Ilan Joselevich (Kranzes) | What does the infra repo use for deploying to nixos hosts? | 22:17:33 |
| Ilan Joselevich (Kranzes) | oh it seems to just use nixos-rebuild | 22:18:58 |
| 5 Jul 2023 |
 Mic92 | it uses https://github.com/numtide/deploykit to run rsync + nixos-rebuild in parallel. | 07:19:30 |
 DavHau | Con someone give me admin access to all nix-community repos starting with dream2nix-? | 09:13:41 |
| Jonas Chevalier | done, except the archived one because it wouldn't let me | 09:23:51 |
| Jonas Chevalier | let me know if you need that one too | 09:24:14 |
| Ilan Joselevich (Kranzes) | In reply to @joerg:thalheim.io
it uses https://github.com/numtide/deploykit to run rsync + nixos-rebuild in parallel. Why don't we use something like Cachix Deploy in CI? | 14:23:07 |
