-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add push-cache-effect #165
base: master
Are you sure you want to change the base?
Conversation
packages = lib.mkOption { | ||
type = with lib.types; listOf package; | ||
description = "List of packages to push to the cache."; | ||
example = "[ pkgs.hello ]"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a default, we could use flakeToOutputs
from hercules-ci-agent
to match the behavior of the default build
https://github.com/hercules-ci/hercules-ci-agent/blob/0e9e67bb7d41ea2bbb13982887ff3b9c511a2aba/hercules-ci-agent/data/default-herculesCI-for-flake.nix#L48
or combine herculesCI.onPush.*.outputs
to match the hercules ci build phase
https://docs.hercules-ci.com/hercules-ci-agent/evaluation#attribute-herculesCI.onPush-outputs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting! Didn't know flakeToOutputs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would involve writing a attribute tree traversal to match the agent behavior, with the right recuresIntoAttrs
behavior, rejecting things with _type
, etc.
That could be done, but I wouldn't encode into this module the assumption that every output should be pushed.
Note also that this effect can not replicate the whole agent behavior, such as pushing all the right build dependencies.
This means that it's not a replacement for the cache that's used by the agents transparently.
More significantly, it also means that this effect is not 100% suitable as a build cache or "development cache", so I doubt that e.g. the checks
or the devShell
dependencies should be pushed by it. A better use case for this effect is as a "release cache" - for only the end products, such as packages, or perhaps also paths for deployment, such as nixosConfigurations
or the inputs of effects (if flake consumers use the same effect functions).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved: we leave it unspecified and the responsibility of the caller since replicating default builder behavior is infeasible.
@@ -0,0 +1,160 @@ | |||
{ lib, withSystem, config, ... }: | |||
let pkgs-x86_64-linux = withSystem "x86_64-linux" ({ pkgs, ... }: pkgs); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should support other systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would see what happens if we try to push non x86_64-linux
derivations using an x86_64-linux
effect before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those will be scheduled during the build phase of the job, and substituted into the agent's store before the effect is launched.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested: pushing derivations built on other systems to attic works.
imports = [ ../../flake-module.nix ]; | ||
|
||
options = { | ||
push-cache-effect = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can have a cachix-push-effect
and attic-push-effect
to mirror cachix-deploy-effect
instead of the type
option. That could resolve passing the type in an unobtrusive way.
effects/push-cache/default.nix
Outdated
secretsMap = { token-file = "${cacheOptions.secretName}"; }; | ||
userSetupScript = '' | ||
attic login \ | ||
server-name \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes for a very confusing error message. We should use server
at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved: using default
.
''; | ||
type = lib.types.attrsOf (lib.types.submodule ({ name, ... }: { | ||
options = { | ||
name = lib.mkOption { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default should be be cachix|attic-push-effect
or cachix|attic-push-${attrname}-effect
to mirror cachix-deploy-effect
.
|
||
``` | ||
"data": { | ||
"name": "my-cache-name", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should name
and endpoint
be in the secret? I think the attribute name can be used as name
, and the endpoint
doesn't need to be secret, it can be an option. But it's convenient to manage together with the token
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think both are acceptable solutions.
832a4a3
to
f5ed263
Compare
needs documentation |
i would separate the two effects since the abstraction is too complicated, there are significant differences, and there is still repetition. |
I'd also add |
@brainrake what if instead |
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-effect
option.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-pkg
cachix-pkg
Maintainer checklist