A challenge that comes up when creating a library or any other tool is setting up a reliable and consistent continuous integration (CI) pipeline for running tests, checks and other tasks. For The Beman Project, it is especially important to have a consistent and reliable CI pipeline that can be used across the full gamut of library projects.

This is where bemanproject/infra-containers comes in. In this post, we'll briefly examine:

• What is bemanproject/infra-containers?
• How does it work?
• How is it used?

What is it?​

In short, bemanproject/infra-containers is a set of Docker container images that can be reused in CI pipelines across the Beman library projects. These containers are automatically built and published to the GitHub package registry under the bemanproject organization. Why do this? There are several advantages:

• These images provide a standard set of tools that are "baked-in" images. There is no further configuration needed in GitHub Actions to get the necessary tooling installed and set up for a particular job.
• This setup gives complete control of specific tools are installed in a particular image.
• The images don't need to be rebuilt for each CI run. They are built once (when changes are made) and then published to a central repository.

Additionally, this setup allows us to build containers that contain pre-release or forked versions of compilers and other tools that may not be available in standard package repositories. This is especially useful for testing upcoming C++ features that are not yet available in stable compiler releases. Currently images are built using the most recent stable versions of GCC and Clang, the most recent trunk builds of both compilers, as well as one for the P2996 reflection fork of Clang.

The infra-containers repository also builds devcontainer images which are used as online development environments via GitHub Codespaces for the Beman library projects.

How does it work?​

When a change is made to the Dockerfile definitions in the infra-containers repository, a series of GitHub Actions are started that build and publish the containers to the package registry, both for production and staging use. These actions additionally run weekly or they can be invoked manually if needed.

If you're not familiar with Docker or containers in general, this may seem like magic. To simplify things, you can think of these images as "virtual" operating systems that have been pre-configured with specific versions of certain tools. For fast turnaround, binary caching, and building compiler forks the CI images are built on top of Gentoo Linux. The devcontainer images are built on top of Ubuntu so that Microsoft's devcontainer images can be used as a base.

How is it used?​

The simplest way to understand how the infra-containers are used is to look at an example. We will use bemanproject/task for this purpose as it runs tests with a large and diverse set of configurations. If we look at its CI GitHub actions workflow, we can see a JSON object used to configure CI. Excerpted below is the Clang portion:

{
  "clang": [
    {
      "versions": ["20"],
      "tests": [
        {
          "cxxversions": ["c++26"],
          "tests": [
            {
              "stdlibs": ["libstdc++", "libc++"],
              "tests": [
                "Debug.Default",
                "Release.Default",
                "Release.MaxSan",
                "Debug.Werror",
                "Debug.Dynamic"
              ]
            }
          ]
        },
        {
          "cxxversions": ["c++23", "c++20"],
          "tests": [
            { "stdlibs": ["libstdc++", "libc++"], "tests": ["Release.Default"] }
          ]
        }
      ]
    },
    {
      "versions": ["19", "18"],
      "tests": [
        {
          "cxxversions": ["c++26", "c++23", "c++20"],
          "tests": [
            { "stdlibs": ["libstdc++", "libc++"], "tests": ["Release.Default"] }
          ]
        }
      ]
    },
    {
      "versions": ["17"],
      "tests": [
        {
          "cxxversions": ["c++26", "c++23", "c++20"],
          "tests": [{ "stdlibs": ["libc++"], "tests": ["Release.Default"] }]
        }
      ]
    }
  ]
}

The structure of this configuration allows maintainers to easily produce CI matrices that test large combinations of compilers, standard libraries, and build configurations. The snippet above generates 29 individual CI jobs, each of which takes around 2 minutes to run individually. The compiler name and version specified here is used to determine which CI image to pull.

Hopefully this brief overview of bemanproject/infra-containers has given you a better understanding of why it's beneficial, how it works and how it's used. If you previously were not familiar with Docker, the GitHub package registry, or even the concept of containers, I hope this has inspired you to dig deeper into the topic to improve your own CI infrastructure at your company or for your personal projects.

Currently, seven beman projects use this beman/infra-containers as part of their GitHub Actions setup, including:

• bemanproject/cache_latest
• bemanproject/execution
• bemanproject/net
• bemanproject/scan_view
• bemanproject/scope
• bemanproject/task
• bemanproject/transform_view

If you're interested in contributing to The Beman Project, including adapting more Beman projects to use the bemanproject/infra-containers setup, please check out the Beman Project on GitHub or join us on Discourse to get involved! Please also checkout the official website for more information on The Beman Project.

During the ISO WG21 C++ Meeting in Sofia, June 2025, we hosted an in-person Beman - Evening Session — a mix of short presentations, a hands-on hackathon, and plenty of big ideas for the future of C++. What started as a relaxed gathering quickly turned into a productive (and caffeinated) brainstorming hub, where we explored potential C++29 library proposals, shared early-stage experiments, and even wrote code live. It was part workshop, part jam session, and fully in the spirit of what makes the C++ community so unique: collaboration, creativity, and a shared passion for pushing the language forward.

Since November 2024, we have been organizing Beman presentations at ISO WG21 C++ meetings (Warsaw 2024 - Poland, Hagenberg 2025 - Austria). Since we have been receiving positive feedback, we decided to organize another one in Sofia, June 2025 - Bulgaria. (Note that our next session will be at CppCon in September in Colorado - stay tuned for more details!)

We had a great turnout, with 25 participants. The evening started with a great discussion about The Beman Project and where it is going, especially considering the C++26 is closed and the design cycle for C++29 is starting.

We presented our first Production ready. API may undergo changes. library, which is the beman.optional library, hoping to get it into the C++26 standard and become Production ready. Stable API.. We counted a total of 10 Under development and not yet ready for production use. Beman libraries.

We have continued the discussion around our set of guidelines for the Beman libraries, which are described in The Beman Standard. This strong set of rules is a great foundation for our libraries, and it helps the authors to create libraries that are easy to use, maintain, and extend by example, using our awesome beman.exemplar template library.

The second part of the evening was a hackathon with our latest tool beman-tidy: The Codebase Bemanification Tool. For more context, the beman-tidy helps you to apply the Beman Standard to your codebase, at a later stage in the library development.

Since the beman-tidy framework was already ready to use, but still required some work to implement around 40-50 checks, we created the beman-tidy Project on GitHub to track the progress of the implementation and to split the work into smaller tasks.

The implication during the hackathon was substantial, with 10 participants working on the beman-tidy framework, and more pushing PRs at a later point in time. The tool is not completed yet, so feel free to contribute (ping @neatudarius on GitHub, which is the beman-tidy author).

We were very happy with the impact of that evening (Wednesday evening, in the middle of the ISO WG21 C++ Meeting), but surprises continued ...

After Friday's LEWG session, P3655R1: std::zstring_view was presented and got feedback to continue the proposed direction. As an immediate consequence of this event, a new author created the beman.cstring_view library, to pursue the C++29 proposal.

The cherry on the cake was the Saturday's plenary! Lots and lots of great news for Beman folks!

The proposals behind the beman.task, beman.execution and beman.net libraries got accepted in C++26, although significant work remains to make them production ready.

Previously, in Saint Louis June 2024, (P3168R2) Give std::optional Range Support was accepted into the ISO C++ Working Draft, which is one of the two papers implemented in beman.optional. The missing piece was the (P2988R12) std::optional<T&> paper, which was also accepted into the ISO C++ Working Draft. That makes beman.optional require just a little bit more work to get it Production ready. Stable API..

We couldn't be happier with the outcome of this event, and we are looking forward to the next one! Please check out the Beman Project on GitHub or join us on Discourse to get involved!

Adobe hosted an exciting and intense half-day Beman hackathon where we worked on adding new Beman libraries, addressed infrastructure issues, and brainstormed designs for the Beman website.

It was awesome to collaborate in person. Here's some of the awesome stuff that got accomplished:

• New Beman tagline: "Tomorrow's C++ Standard Libraries Today". Thanks Nick DeMarco for this great contribution!
• std::elide paper implementation from Robert Leahy, a first time contributor!
• Linus Boehm made some great progress creating a std::indirect/std::polymorphic Beman library.
• We had several discussions on the future of the exemplar library.
• River Wu identified root cause of an ASAN hanging issue.
• Eddie Nolan and I sketched out a rough design for the new website.

Overall it was productive and a ton of fun. Thanks to Robert, Eddie, Linus, River, Nick, Bret, and Robert for participating!

I met Beman Dawes when I attended my first C++ committee meeting in 1997. I wasn’t even a committee member at that time; I showed up at the meeting because I was trying to get exception safety into the C++ standard and Andrew Koenig had made it clear that arguing for it over email wasn’t going to cut it; I needed to show my face.

I didn’t know what to expect; I sat in one of the chairs at the edge of the room while the committee took seats at a big “U” of tables in the center. After some preliminary business, the meeting broke into Core and Library “working groups.” Since exception safety was mostly a library issue, I stayed with the library group, of which Beman was the chair.

Beman started by asking me to join the other members in the center of the room and filling me in on the job at hand: working through issues people had reported with the draft C++ standard. That was my first indication of the extraordinarily inclusive tone he set for these meetings. Everyone, and every idea, was treated with collegial respect, and the spirit of openness and contribution flowing from Beman had clearly “infected” the other participants. I cautiously made a few points, which were greeted with appreciation, where I thought I could contribute.

I left that meeting with the realization that it was possible to work together in a way I had never experienced in my regular job, driven by consensus, and that this spirit both raised the level of discourse, and produced better results, than what I had seen before. It put the lie to the disparaging phrase “designed by committee.” So when Beman proposed that we start the Boost Libraries project, I was immediately on board. His idea for Boost would blossom into a unique community of collaborative library designers because of the example he set.

As we grew Boost over the years, so grew our friendship, and when Beman passed away suddenly in 2020, it was a great loss to me personally, and, I think, to the world of programming. Beman never sought the spotlight, and I always wondered what would become of his contribution, which was surely underappreciated. That’s why I was so thrilled to hear that a modern C++ libraries project was being launched in his name. May it continue to demonstrate Beman’s commitment to community and excellence.