Add CI workflows

[ariostas]

This PR implements CI workflows to perform static checks with clang-format and clang-tidy, as well as to perform test runs of the code in standalone and cmssw setups.

The static checks are performed automatically for all commits to PRs. The CI doesn't fix anything, but it gives warnings for formatting and other potential issues. I couldn't get clang-tidy to work perfectly, but it works well enough for now. My plan is that when in a few months the CMSSW integration has progressed enough, I'll update the workflow to use scram b code-format and scram b code-checks to more accurately mirror what is done by the cmsbuild bot.

The testing workflows are triggered by leaving comments on PRs containing /run standalone and/or /run cmssw. The latter command accepts an optional argument to specify the branch of the CMSSW fork that should be used.

I have documented everything more extensively in the .github/workflows/README.md file and in the SegmentLinking/TrackLooper-actions repository.

[VourMa]

/run standalone

[VourMa]

/run standalone

I was hoping that this would work for this PR, as the CI worked but I guess I was mistaken. As a result, there is not easy way for me to check how this works.

[VourMa]

In CI results of this PR I see multiple mentions of /cvmfs/cms.cern.ch/common/scram: 14: COUNT++: not found. Is this something to be fixed?

[VourMa]

In (SegmentLinking/TrackLooper-actions/cmssw/action.yml](https://github.com/SegmentLinking/TrackLooper-actions/blob/main/cmssw/action.yml), I see a mention of your username, @ariostas. Is this going to work for others? Does it make a real difference?

[VourMa]

All in all, does it make sense to just merge this PR to be able to test it in action? I couldn't find any smoking gun issues, apart from the minor comments above, and I don't think that anything would break in any case.

[ariostas]

@VourMa thanks for your comments.

Unfortunately, as you said, we can't self-test this PR since this action runs only when it's in the main branch.

The errors you're seeing are expected. I'm running the setup script to set some environment variables, but since the linux version doesn't match what cmssw expects there are some issues, but it doesn't affect anything that we need.

As for my username, it appears because I'm storing the docker images in my personal docker hub account. They have restricted a lot when it comes to free organization accounts, but if you prefer we can create some personal account for LST and store it there. I added instructions in the docker folder of the actions repo for how to do this if we need to move the images somewhere else later on.

If you want to try things you can look at the repo in the SegmentLinkinTests organization. But I think it makes sense to just merge it. If something is broken most likely we'll be able to fix it from the other repo. But I tested things, so everything should be good to go.

[VourMa]

Thanks for the reply!

As for my username, it appears because I'm storing the docker images in my personal docker hub account. They have restricted a lot when it comes to free organization accounts, but if you prefer we can create some personal account for LST and store it there. I added instructions in the docker folder of the actions repo for how to do this if we need to move the images somewhere else later on.

I think this is ok as long as it works for others. The instructions are useful for the long-term, thank you!

If you want to try things you can look at the repo in the SegmentLinkinTests organization. But I think it makes sense to just merge it. If something is broken most likely we'll be able to fix it from the other repo. But I tested things, so everything should be good to go.

If I merge, would I be able to run the /run standalone command in my PR, so that we test like that? Or would I have to rebase my source branch of that PR or something?

[ariostas]

@VourMa you can run it with your PR after merging. You don't need to rebase. However, the formatting won't be checked unless you push something new. Maybe let's make sure that the forgetting is fine by manually running clang-format.

[VourMa]

From a first look, the code looks good. I am approving and merging this, so that we can test it in action. In case we find a cornercase where things don't work as expected, we will fix it in a follow-up PR.

[VourMa]

However, the formatting won't be checked unless you push something new. Maybe let's make sure that the forgetting is fine by manually running clang-format.

Should I just push a "dummy" commit to PR #358 to trigger the tests? Or should I run something manually on my terminal?

[slava77]

is there a way to run the code checks locally without the CI?

[ariostas]

If you want to check formatting you can run clang-format -i -n SDL/*.h SDL/*.cc. To apply the changed you simply remove the -n flag.

To check with clang-tidy is more annoying. It should be something like this.

INCLUDE_FLAGS="-I$TRACKLOOPERDIR -I$BOOST_ROOT/include -I$ALPAKA_ROOT/include -I$CUDA_HOME/include -I$ROOT_ROOT/include -I$CMSSW_BASE/src"
INCLUDE_FLAGS="$INCLUDE_FLAGS -I/cvmfs/cms.cern.ch/el8_amd64_gcc11/external/gcc/11.4.1-30ebdc301ebd200f2ae0e3d880258e65/include/c++/11.4.1"
INCLUDE_FLAGS="$INCLUDE_FLAGS -I/cvmfs/cms.cern.ch/el8_amd64_gcc11/external/gcc/11.4.1-30ebdc301ebd200f2ae0e3d880258e65/include/c++/11.4.1/x86_64-redhat-linux-gnu/"
INCLUDE_FLAGS="$INCLUDE_FLAGS -I/cvmfs/cms.cern.ch/el8_amd64_gcc11/external/gcc/11.4.1-30ebdc301ebd200f2ae0e3d880258e65/lib/gcc/x86_64-redhat-linux-gnu/11.4.1/include"
clang-tidy SDL/*.h SDL/*.cc -- --language=c++ -std=c++17 -DALPAKA_ACC_CPU_B_SEQ_T_SEQ_ENABLED $INCLUDE_FLAGS