Add populate-cache-effect#163
Conversation
|
|
||
| options = { | ||
| populate-cache-effect = { | ||
| enable = lib.mkOption { |
There was a problem hiding this comment.
I prefer to make a more the description of enable longer than what mkEnableOption does, so I'm always happy to forget its syntax and just write it out.
I think the description on the line below is a good place to explain the relevance and some subtleties of this effect, that can't be captured in the other options. E.g.
description = ''
Enables an effect that pushes certain outputs to a different binary cache.
Hercules CI normally pushes everything to the cache(s) configured on the agent. This effect supplements that behavior by letting you push a subset of those to a different cache.
'';There was a problem hiding this comment.
Also:
Note that it only pushes the output closure, and not the closures of build dependencies used during the build stage of the CI job. (Unless those closures happen to also be part of the output or "runtime" closure)
There was a problem hiding this comment.
Hasn't mkEnableOption an optional description argument?
There was a problem hiding this comment.
I discussed this with someone at some point, but I don't think anyone followed through on it. It'd be nice.
| description = "Enables HerculesCI effects populating some external cache."; | ||
| }; | ||
| attic-client-pkg = lib.mkOption { | ||
| type = lib.types.package; |
There was a problem hiding this comment.
used it but reverted in the end to keep consistent with attic-pkg option
| secretName = lib.mkOption { | ||
| type = lib.types.str; | ||
| description = '' | ||
| Name of the HerculesCI secret. See [HerculesCI docs](https://docs.hercules-ci.com/hercules-ci-agent/secrets-json). | ||
| The secrets "data" field should contain given data: | ||
|
|
||
| ``` | ||
| "data": { | ||
| "name": "my-cache-name", | ||
| "token": "ey536428341723812", | ||
| "endpoint": "https://my-cache-name.com" | ||
| } | ||
| ``` | ||
|
|
||
| The "endpoint" field is needed for Attic cache. With Cachix cache the "endpoint" field is not read and can be absent. | ||
| ''; | ||
| }; |
There was a problem hiding this comment.
I would add a default for this option (e.g. "hci-cache-${name}-settings") in order to decrease the amount of needed boilerplate.
There was a problem hiding this comment.
Fewer defaults means it may be easier to grep for usages of a secret.
Ideally the underlying search problem could be solved with tooling, so I'm on the fence about this issue.
There was a problem hiding this comment.
I hadn't even asked myself this search problem, I defer to your judgement :)
There was a problem hiding this comment.
I would leave without a default as otherwise there is still strong coupling to an outside piece of configuration only it's hidden away, which is worse. I find myself spending a lot of time figuring out these hidden globals in various systems.
| branches = lib.mkOption { | ||
| type = with lib.types; listOf str; | ||
| description = '' | ||
| Branches on which we'd like to execute the effect. | ||
| ''; | ||
| }; |
There was a problem hiding this comment.
How should I set this option if I wanted to push to the caches for all the branches? Moreover I believe that this behavior should be the default one.
@roberth effects aren't executed on forks, are they? Just to be sure, we don't want that people are able to push outputs to our caches simply by forking our repos.
There was a problem hiding this comment.
Correct, onPush only activates for the "local" repo - ie the one that had Hercules CI installed on it via GitHub, in the organization for which the agent is configured to run.
Any exceptions to this rule will be opt-in, one way or another, because it's important for security. After all, CI can be described as pure "remote code execution".
There was a problem hiding this comment.
@aciceri Right. Let's use nullOr (listOf str) for that?
| inputs.attic = { | ||
| url = "github:zhaofengli/attic"; | ||
| inputs = { | ||
| nixpkgs.follows = "nixpkgs"; | ||
| }; | ||
| }; |
There was a problem hiding this comment.
Unfortunately attic is not in nixpkgs (not even the client). Personally I don't like forcing an extra input to all the hercules-ci-effect consumers (inputs are not lazy). Moreover we don't get caching for it.
Perhaps we should consider adding it to nixpkgs (should be trivial, I'm referring only to the client derivation) or leaving to hercules-ci-effects consumers the burden to fetch that derivation and set it here.
There was a problem hiding this comment.
It is unfortunate that transitive inputs are so "in your face". I intend to change this in Nix, but with limited resources.
See NixOS/nix#7730
Until then I agree it's perhaps best not to have a flake-level dependency like this.
Ideally it could be added to Nixpkgs. A cheap way to "solve" the problem is by making it the caller's problem:
default = pkgs.attic or (throw "<option>: It seems that attic hasn't been packaged in Nixpkgs (yet?). Please check <nixpkgs packaging request issue> or set <option> manually.");If that proves infeasible, we could consider doing something custom.
There was a problem hiding this comment.
Nixpkgs package request: Attic NixOS/nixpkgs#232532
There was a problem hiding this comment.
Resolved: fixed (made it caller's problem).
|
You're using push and populate interchangeably, but push seems to be the established term for what we're trying to achieve. Perhaps populate could be renamed to push, or does that lose something subtle I don't catch on to? |
|
There's a potential "trap" (affectionately) because the cache name is not necessarily unique between cache providers / instances. |
|
What if we have something like: caches = {
"attic:foo" = {
# ...
};
"cachix:foo" = {
# ...
};
}Where the attrset name is parsed and used to set the cache's |
I like this. It's basically the "store URI" concept in Nix, but then extended to ones Nix does not actually have, which kind of begs to support the ones that Nix supports natively, such as S3. Ideally this effect would be usable outside a flake-parts context as well, but I know that it's currently non-trivial how to get good reuse between flake-parts modules and |
I dont think there's problem. The |
|
Thanks for review @aciceri and @roberth. I'll shortly apply the suggestions, only one think I don't know is where to export this flake-parts module from the flake then? I didn't like that it's flake-part module specifically and not |
| @@ -0,0 +1,179 @@ | |||
| {inputs, withSystem, ...}: | |||
| let | |||
| attic-client = inputs.attic.packages."x86_64-linux".attic-client; | |||
There was a problem hiding this comment.
Why here is hardcoded x86_64-linux system, shouldn't we use herculesCI.ciSystems here?
There was a problem hiding this comment.
Maybe, because I dont understand how system plays with effects.
@roberth Could you help? Am I free to use any system I find convenient for effect definition? What happens if I mention darwin derivation paths in my linux (linux in a sense that it uses withSystem "linux" ({hci-effects}: ...)) effect?
Specifically here, do I need separate effects for pushing paths for different systems to cache?
There was a problem hiding this comment.
|
Moved to mlabs-haskell#1 to allow edits |
|
moved to #165 to originate from the same branch as the demo project |
|
Regarding passing the |
|
I have reviewed all the above comments and moved everything unresolved to the new issue #165. |
Motivation
We want to push some paths to either the cachix or attic cache, additionaly to the cache configured for herculesCI. We discussed it recently on mlabs slack. If you guys would be interested here's a module doing that to be used like below:
it's a flake-parts module producing effects under
herculesCI.onPush.default.outputs.effects.populate-cache-effectoption.Questions
It works. But I don't understand the structure of this repository, so I'd like to ask first how to incorporate that into the codebase:
attic-client-pkgcachix-pkgMaintainer checklist