Should we have a dedicated repo for infrastructure?

Beman Project Development
1

We are talking about build matrix, linters, debug on CI etc. My preference would be have a dedicated repo for infrastructure and be able to use as dependency in each repo (e.g., optional26 to have as a submodule this infrastructure repo; I’m open to any dependency like support - need to test this idea).

Advantages:

  • no duplication for infrastracture
  • fast way to deliver updates
  • we can have a stable branch/version which is pulled by other repos and keep main as a development branch.

We didn’t have time to discuss this at the sync. Open earlier discussion here.

It may simply other choices such as version 2 from What clang-format config should we adopt??

It may also help for managing supported images to run Beman (Should we use or remove Docker from Beman?).

1 Like
2

I would say yes, for the reasons you listed. It will greatly reduce duplication and also make it easier for existing Beman projects that are missing some aspects of infrastructure to integrate it.

1 Like
3

Additional needs:

  • Reducing CMake boilerplate
  • Making it easier to support library layout expectations on different environments
  • Making GitHub Actions less repetitive by having common build-run-and-test scripts, etc.

I have had in mind adding dependencies to account for the above also. But I have been hesitant to do so before we get some reasonable support for Conan and vcpkg.

It would be possible to use FerchContent for this, I believe. Perhaps that is the best option for now. But we should be willing to prioritize support of packaging, even if we have to rethink our use of git-submodules, for instance.

4

The downside of having it outside the project is that projects get broken by changes outside their span of control. With a distributed project we can’t even do a forkift upgrade of everything in github, because that still means peoples working branches are broken.

If the infrastructure is shared, it also tends to be frozen because of the perceived costs of change.

5

I think this idea is worthy of further investigation, but it’s hard to know if it would be better without knowing exactly how it is implemented. Submodules confuse people, it’s unclear how FetchContent would work with pre-commit, .clang-format wants to live in the top-level directory, incremental dependency upgrade paths, etc.

@neatudarius do you have a concrete idea for how a separate infrastructure repo would work? Without that I’m afraid it’s tough to give feedback.