Steam Engine: Bors for Merge Train

[zimbatm]

@zimbatm

• move some of the ofborg capability to GitHub Actions if possible.

Let’s shelve that discussion, for now, it’s a bit out of topic.

[timokau]

@kevincox

@zimbatm

or extend ryantm-updater to delegate PRs to maintainers.

If you mean bors delegate I’m not sure we can do that because we can’t trust that they don’t add more to the PR that is malicious/affects other changes.

It seems that we will need a status-based policy check anyways and at that point we can in theory open up to a wide audience. (Although that depends on how much we trust bors).

Not if its restricted to r-ryantm’s PRs. I like that idea a lot, since it can improve throughput without a lot of hairy trust discussion. Its a nice way to dip our toes in the water.

[kevincox]

Ah I see. That makes sense! I was thinking of marvin for some reason

[blaggacao]

As secretary of the SIG, I’m factoring out some of the interesting discussion stumbs from this “Steam Engine” as so called “Geistesblitze”:

• Geistesblitz: Empower our Trust Model through a Policy Decision Agent
• Geistesblitz: Well defined JSON schema for ecosystem build tool outputs - #2 by blaggacao
• Geistesblitz: Bors policy enforcement with revocation

Please feel free delivering your own “Geistesblitz” through the templates provided in the footer of the SIG Workflow automation description page. Keeping the discussion going is an important intrinsic motivator for all of us. Thank you all for your contributions!

[blaggacao]

Public note to self:

• Corollarily, I want to touch GitHub - palantir/bulldozer: GitHub Pull Request Auto-Merge Bot
• … in the context of GitHub - palantir/policy-bot: A GitHub App that enforces approval policies on pull requests
  • … as a complement to Geistesblitz: Empower our Trust Model through a Policy Decision Agent

[blaggacao]

Owing to those damn megalomaniac tendencies of mines, across investigating bors & friends, I was constantly looking into ways to tackle this whole topic from a different, better (a.k.a more megalomaniac) angle, that also happens to be fundamentally in line with other (ad)ventures I’m currently working on.

I stumbled over zeebe.io (no personal stake in it, just a nastily great tool for SIG Workflow automation). For which I recently started working on a <wip> golang DDD code generator </wip> that is/will be able to bootstrap an event driven golang backend based on clean architecture and domain driven design with a very crude OPA policy interface.

After having given away myself by those links as a very terrible programmer (I’m not actually one!), there shall be merits to this thinking. In my chasing mind, those concepts amalgamate:

• A DDD framework to very easily implement custom business logic and state as needed (github agnostic! — @7c6f434c)
• A zeebe.io orchestrator through version controlled BPMN2.0 graphical “docplementation” of ecosystem workflows (of any sort and as needed).
• An OPA policy agent enforcing version-controlled and -condocumented policies as suggested in Geistesblitz: Empower our Trust Model through a Policy Decision Agent

… amalgamate into a clean ecosystem workflow automation platform that is superior to other solutions by means of leveraging two-birds-one-shot principles wherever possible, such as BPMN2.0 workflow graphics being dual use (doc and implementation) or having policy decided and implemented upon the same PR (OPA’s rego policy language).

Let me know what you think. Isn’t that too megalomaniac, insane & whatever, but actually a nice idea?

[notriddle]

I admit that I’m not a NixOS dev, so I don’t truly have a stake in this, but can I give some unwarranted advice?

1. Trying to make your workflow agnostic to your issue tracker and code review platform is a fool’s errand. I’ve tried. You either use something other than GitHub (like GitLab, Jira, Jenkins, Gerrit, etc), and couple your workflow to that instead, or GitHub-isms leak into it anyway, and you’ve wasted a bunch of time on “platform agnosticism” that doesn’t actually allow you to switch platform easily.

2. Think of it as if you had a “weirdness budget”, which is really just a proxy for how much time you expect contributors to spend learning your idiosyncratic tooling. They already have to learn Nix. Do you really want to force them to learn your code review system, too, or your very weird way of using them?

[blaggacao]

Oh thanks for your feedback. I think you’re on the page on advocating for the best possible on-boarding experience. I’d say on-boarding UX continues to be a construction site. I agree with you, that we should use as much github (that is “well known”) for front-end as possible.

As far as the workflow back-end is concerned, an emerging nix security and trust model might require more policy expressiveness than off the shelve tooling might allow us to.