Closed zimbatm closed 4 months ago
The privacy
option on teams makes me think we should not make this kind of data public, but likely only available to org members. Also, it should possibly go into a dedicated repo, so the commit log is the undisturbed audit log.
The question of who or what would be applying the changes is also up in the air (given that the token has so much power).
Ideally through CI, so execution and effect can become observable.
YAML may cause various issues due to its classical caveats if it's edited by humans and that there's improper validation on the tool side (e.g. type homogeneity enforcement).
If we use this syncing teams between nixpkgs and github should be relatively trivial. If it's not too hacky we can probably just have our own wrapper that fetches the current nixpkgs master with a depth of one and does something like:
nix-instantiate --expr 'let pkgs = import ./. { }; lib = pkgs.lib; in lib.teams' --eval --json --strict
Then we have all the team names and github handles of people in the teams.
Thanks for the feedback.
The privacy option on teams makes me think we should not make this kind of data public, but likely only available to org members.
AFAIK we don't and shouldn't have anything secret. But let me know in DM if I missed something. I can still force-push and hide this commit.
Also, it should possibly go into a dedicated repo, so the commit log is the undisturbed audit log.
Agreed, I wanted to share the POC before creating a new repo. Name idea: infra-peribolos
YAML may cause various issues due to its classical caveats if it's edited by humans and that there's improper validation on the tool side (e.g. type homogeneity enforcement).
I will see if I can add TOML support to peribolos since it's easier for Nix and humans to consume. I also want the tool to be able to merge multiple files together, so we can split things out a bit.
^ that will be my next step.
If we use this syncing teams between nixpkgs and github should be relatively trivial.
Good idea. One feature of the tool is that it doesn't touch teams if they are not listed, so we can have both side-by-side for the initial deployment. After it's deployed, that would be a good next step.
Name idea: infra-peribolos
I think going with something like nixos/github-config
would make it much easier to find.
This idea looks oddly familiar (though not quite the same as) something I just happen to be drafting out right now! I'd like to first discuss this a bit with @zimbatm in PMs (messaged you).
Making the proposal more public now: https://github.com/nix-rfc-org/rfcs/blob/nix-rfc-org/rfcs/0000-open-org.md
Chatted with @zimbatm today, and we agreed on the direction this is going, and that both this PR and the proposal work towards the same goal, the PR from the implementation side, with the RFC from the social/community side.
This is a POC to see how the peribolos config could work for us.
The idea would be that anybody can submit a PR to change the NixOS org configuration, making the changes more transparent and available.
The peribolos/config.yaml contains a dump of the NixOS and NixCon orgs and needs to be cleaned up a bit. Notably, the list of org members and nixpkgs committers needs to be removed as it is handled by a separate tool.
My first impression so far:
Otherwise it looks pretty good so far.
I haven't tested the application of changes yet, this needs to be tested on another org first.
The question of who or what would be applying the changes is also up in the air (given that the token has so much power).