Hi All,

Apologies if I mess up the mailing list, my first time using mutt and
discussing things this way.

Just wondering if there is anyone who has built anything similar to the
'automatic merge' when approved and passed CI like some other services
have. I figure the analogue here would be something watching the mailing
list for 'approved' email signed by a valid GPG key, then the bot would
merge it back to main.

Currently this would probably need to be automated outside of sourcehut.
As you would need to maintain some secret to update the master.

My 'user story' for this one, is I have used dependabot and Github and
CD to end up updating versions of apps from my mobile device. It's quite
a nice experience to look at the version bump of a dependency, see that
it passed my unit tests, and have it kick off some orchestration putting
the version on my app servers once merged. 

I love the concept of using mailing lists, but figure there would be a
fair bit of DIY to build a similar user experience. So wondering if
there is any prior art in this space.

Regards,
Beau

> My 'user story' for this one, is I have used dependabot and Github
> and CD to end up updating versions of apps from my mobile device.
> It's quite a nice experience to look at the version bump of
> a dependency, see that it passed my unit tests, and have it kick off
> some orchestration putting the version on my app servers once merged.

Not a SourceHut maintainer, but if version pinning can be determined
automatically at build time (or via CI), it should not be hardcoded.
This often gives downstream maintainers unnecessary troubles.

I strongly suggest prefer blacklisting dependency versions
over whitelisting.

On April 2, 2022 5:45:24 AM GMT+02:00, Beau Trepp <beautrepp@gmail.com> wrote:
>Just wondering if there is anyone who has built anything similar to the
>'automatic merge' when approved and passed CI like some other services
>have. I figure the analogue here would be something watching the mailing
>list for 'approved' email signed by a valid GPG key, then the bot would
>merge it back to main.
>
Yes. There are similar things out there. I couldn't find a blogpost describing the setup I read about, but kernel maintainers, e.g. Greg Kroah-Hartman, do similar things (and have done so for a long time).

They typically subscribe to the mailing list as usual and get a set of scripts with procmail or something like that that process the messages. They can apply patches, run tests, autorespond... It's up to the script what to do with that.

I have not checked, but sourcehut may already be doing part of this for patch CI. You could check and copy/extend it for merges as well.

I'm not part of the project but I doubt such a feature would be added. It has several potential issues and can be set up by the maintainers as described above if desired.

Hope this helps you figure out your use case.

Regards,
Miguel

Hi!

On Sat Apr 2, 2022 at 5:45 AM CEST, Beau Trepp wrote:
> Just wondering if there is anyone who has built anything similar to the
> 'automatic merge' when approved and passed CI like some other services
> have. I figure the analogue here would be something watching the mailing
> list for 'approved' email signed by a valid GPG key, then the bot would
> merge it back to main.

The easier way would be probably to query the patch's status using the
API, but this would not be the main problem. SourceHut's CI is intended
to run if there is code to be run through; which is what happens:
Pipelines are triggered when new code becomes available either through
push or through the mailing list. (Or through the API)

Replies to the mailing lists do not trigger new builds.

> Currently this would probably need to be automated outside of sourcehut.
> As you would need to maintain some secret to update the master.

This part would be relatively easy… just add a SSH key to your secrets
and push with that.

> My 'user story' for this one, is I have used dependabot and Github and
> CD to end up updating versions of apps from my mobile device. It's quite
> a nice experience to look at the version bump of a dependency, see that
> it passed my unit tests, and have it kick off some orchestration putting
> the version on my app servers once merged.

The thing is: there is no dependabot here. So this is something you'd
have to do on your own. And while you're at it you might as well run
these checks on your side and push the changes if it works.

> I love the concept of using mailing lists, but figure there would be a
> fair bit of DIY to build a similar user experience. So wondering if
> there is any prior art in this space.

It's not intended to be similar. The mailing list approach is completely
different to the Pull-Request approach, simply because the former allows
for open participation by everyone and contrary to PRs does not require
you to give anyone your data, except your Email-Address and your
feedback.

Trying to cram the mailing list approach into the PR scheme is bound to
lead to numerous issues and will likely cause some friction with the
SourceHut team as well, if you happen to implement something wrong and
spam builds.

My recommendation would be to:

a) setup a mirror on GitHub and run dependabot there, then apply the
   changes to your tree and push them to sourcehut
b) skip the middleman, check your dependencies from time to time and
   update as needed. You don't always need the newest and shiniest
   version. (Security fixes being the obvious exception here)

--
Moritz Poldrack
https://moritz.sh