Hi there! I pushed an update to builds.sr.ht a couple of days ago which
allows you to add an arbitrary number of build manifests in the .builds
directory of your repository, which are all submitted each time you
push. I've been thinking about ways to improve this even more, and want
your feedback on this idea.

What if, when you push, git.sr.ht looks for build manifests in any
directory that your changes affected and submits them. Say your repo
looks like this:

.build.yml
src/
    main.c
    .build.yml
test/
    test_main.c
    .build.yml

If you push changes to src/main.c, it would submit .build.yml and
src/.build.yml. One use-case I'd have for this is the builds.sr.ht image
build scripts, which live in the builds.sr.ht repo under
images/$distro/$release. If I make some changes to the build scripts, it
would be nice to automatically rebuild them.

Would anyone else have a use-case for this?

That's a neat idea.  While I personally don't have a use-case for
it at the moment, I've worked on projects with large monolithic
repos (comprised of >20 packages) and having the ability to build
the packages individually and as a whole would've been nice.

  -amin

> Would anyone else have a use-case for this?

In the Haskell world, it is relatively common to store a number of
related packages in a single project-level repository[1]. The feature as
proposed is almost useful - if I change a package I can rebuild it
alone, but I would also want to rebuild its local reverse dependencies
without replicating too much.

In the repo I linked[1], sv-cassava depends on sv-core. A granular CI
for this project would want to rebuild sv-cassava when sv-core
changes. I see two obvious ways to do this:

1. Allow build manifests to declare dependencies, and not bother
   starting if a dependent build failed.

2. Allow build manifests to trigger other builds on success.

I generally favour declarative configuration over imperative, and here I
think declarative style (#1) makes cycle detection and other things
easier once more features get added to the build manifest format.

However, I wouldn't be keen to split a project into per-package builds
unless it was getting really large: a separate build for each directory
means downloading GHC etc N times per-affected-package. Maybe once
caching is under control?

[1]: https://github.com/qfpl/sv . Note the cabal.project file in the
root.

-- Jack