Closed non-det-alle closed 11 months ago
@pagmatt If it's ok for you, now I'll focus on restoring github workflows on the line of the ones of ns-3.
Makes sense to me! How do you plan to do that? Fork on Gitlab the ns-3 repo and set this as a submodule, or define the CI here? I believe we may run out of CI time if we do it here for all the ns-3 mainline CI actions
The problem I see with the submodule option is that CI actions would not run automatically for MRs. It would require an additional fetch & commit from the ns-3 fork perspective to activate the CI actions there, right? And this would only work on changes already merged, so contributors would not be able to fix the problems directly in the MR.
I propose we first try to fix the CI here. I was thinking of cutting down the number of actions in the main ns-3 repo. For instance, we can start by running them exclusively on ubuntu images with a single compiler (as they are now) and focus on building, testing, formatting and documentation.
The MR one is a good point. Let's try to fix the CI here then, ideally I'd like to keep publishing the documentation on Github pages as well. I can take care of that myself actually.
Apply ns-3 .clang-format rules to all files of the module using ns-3's check-style-clang-format.py. No additional changes beyond formatting.
This merge is meant to break up a previous huge pull request into more digestible pieces.