Add tools-rippled-clang-format

[Bronek]

Aside from build images, XRPLF projects also use container images with specialized tools, e.g. to enforce code formatting, run sanitizers, run code coverage tools etc. The required images are created by workflows starting with tools- and ending with the project name e.g. tools-rippled, and are only meant to support specific projects. These images may also contain a complete C++ build environment, if needed.

This change adds the image for clang-format.

[bthomee]

• With the tools image, are there packages that can be removed from the Debian, RHEL, and Ubuntu images?
• The tools image for rippled contains a few packages that had been added for Clio (e.g. bison, flex) that can probably be removed here.

[Bronek]

With the tools image, are there packages that can be removed from the Debian, RHEL, and Ubuntu images?

I think we can get rid of gcovr when this is merged; I would keep it for now in #4 , so we have a sequence of changes rather than making assumptions about not-yet-ready PR.

The tools image for rippled contains a few packages that had been added for Clio (e.g. bison, flex) that can probably be removed here.

As long as they are not needed to actually build clio, or run its unit tests, or package it, they can be moved to tools-clio (which this PR could also include, after change of the subject line of course).

[bthomee]

The tools image for rippled contains a few packages that had been added for Clio (e.g. bison, flex) that can probably be removed here.

As long as they are not needed to actually build clio, or run its unit tests, or package it, they can be moved to tools-clio (which this PR could also include, after change of the subject line of course).

@mathbunnyru which of the tools that I added to the base images are not needed to build Clio?

[mathbunnyru]

The tools image for rippled contains a few packages that had been added for Clio (e.g. bison, flex) that can probably be removed here.

As long as they are not needed to actually build clio, or run its unit tests, or package it, they can be moved to tools-clio (which this PR could also include, after change of the subject line of course).

@mathbunnyru which of the tools that I added to the base images are not needed to build Clio?

I don't think we need bison, curl, flex, wget (but I'm ok keeping curl and wget to make images easier to use)

[bthomee]

Since the idea is to make separate tools-clio-X images containing the tools they need, such as bison and flex, should we just remove them already from all three dockerfiles in this PR?

Separately, I know that to enable coverage analysis it is needed to enable -Dcoverage=ON when building. Is it really more efficient to trigger a separate job for just coverage that will need to build from scratch (I don't think we yet have a good way of caching intermediate build artifacts?), as opposed to just running it as part of the regular build+test for just one of the matrix combinations?

For example, in the rippled CI we'd then eventually have something like:

matrix:
  mode:
    - Debug
    - Release
  os:
      - image: jammy:gcc-12
         platform: linux/amd64
         runner: ubuntu-24.04
      - image: jammy:gcc-12
         platform: linux/arm64
         runner: ubuntu-24.04-arm
         [...]

And in the CI pipeline you just activate the coverage option & upload the report when mode == 'Debug' && image == 'noble:gcc-14' && platform == 'linux/amd64'. Yes, Gcovr would be part of images where it would never be used, but it would avoid launching a completely separate job for just coverage that would use extra compute.

Similarly, setting -Dvoidstar=ON could be done similarly. Would could enable coverage and instrumentation at the same time.

[Bronek]

Since the idea is to make separate tools-clio-X images containing the tools they need, such as bison and flex, should we just remove them already from all three dockerfiles in this PR?

Yes I guess, in the appropriate PR which creates tools-clio-X - which is not this PR.

Separately, I know that to enable coverage analysis it is needed to enable -Dcoverage=ON when building. Is it really more efficient to trigger a separate job for just coverage that will need to build from scratch (I don't think we yet have a good way of caching intermediate build artifacts?), as opposed to just running it as part of the regular build+test for just one of the matrix combinations?

That is not such a good idea - unit tests run slower when coverage is enabled.

And in the CI pipeline you just activate the coverage option & upload the report when mode == 'Debug' && image == 'noble:gcc-14' && platform == 'linux/amd64'. Yes, Gcovr would be part of images where it would never be used, but it would avoid launching a completely separate job for just coverage that would use extra compute.

I guess that's a good idea, but such change does not belong here and also, -Dcoverage=ON would have to be subject to the same switch (as not to slow down all unit tests, as explained above).

Similarly, setting -Dvoidstar=ON could be done similarly. Would could enable coverage and instrumentation at the same time.

Can use a similar (but not the same) switch for instrumentation check, but note that we can only use this option with Clang compiler. Also, it might similarly slow down unit tests, just a little.