CI/CD: Request for improved clarity on how release artifacts are built

[orthorhombic]

For a current project I'm working on, I'm trying to compile SCIP (on Debian) with different options and would like to do so in an automated fashion, so I'd prefer not to reinvent the wheel. Specifically I'm looking to set TPI=tny or omp for concurrent solves.

In reviewing the documentation/code for SCIP I've been struggling to understand how the release artifacts are compiled/built. Can someone point me to where this is documented or share the code in the scipopt GitHub organization? I've summarized what I was able to find below.

• I've found a reference to an internal Jenkins/GitLab being used in https://github.com/scipopt/scip/issues/55.
• This commit seems to have disabled GitLab CI, so I suspect that may not have been used for the release: https://github.com/scipopt/scip/commit/4c9d64e778ef67b35594896bbbc7367ec9e4828a
• Updates to this seem to correspond in timing with the last release, but doesn't build the artifacts on the release page: https://github.com/scipopt/scipoptsuite-deploy/blob/main/.github/workflows/build_binaries.yml
• I haven't been able to find any Jenkins files.

Any insight is appreciated, and if there is a better place for this discussion please let me know. Thank you for all your hard work!

[svigerske]

Yeah, there are many public and secret build scripts around for the SCIP OptSuite. So you wouldn't be the first one to reinvent the wheel.

Dockerfile.txt is the Dockerfile used to build the SCIP Optimization Suite for Debian12/x86_64, except that it has TPI enabled now. Dependencies that are installed there are a bit outdated, and the binaries that come out require a number of dependencies to be installed by the user, so there is room for improvement. Also, in our internal tests, concurrent solve neither works with TPI=tny nor TPI=omp reliably, but omp is particular bad at the moment.

[orthorhombic]

Thank you for the info! I'll try out that Dockerfile in the coming days.

Is there a reason there are "many public and secret build scripts around"? Are CI/CD development and improvements strictly internal? Being new to this project, I'm unfamiliar with what is internal or external and why. Apologies if I'm overstepping.

As for your insight on the concurrent solve, I'll definitely be wary of sinking too much time into trying to get it working. Even if I end up not using concurrent solve, are there any known issues with using binaries where TPI is set (e.g. using without multiple threads)?

[svigerske]

Is there a reason there are "many public and secret build scripts around"?

Procrastination, lack of communication, preference of tools, ...

Are CI/CD development and improvements strictly internal? Being new to this project, I'm unfamiliar with what is internal or external and why. Apologies if I'm overstepping.

Traditionally, most of it is internal. The GitHub projects are just mirrors of some branches of internal projects. There are here to give users easy access to the latest main stable branches, and to provide an additional issue tracking system for user requests. But most development and communication between developers is internal. The CI also runs on machines that are not publicly available.

Even if I end up not using concurrent solve, are there any known issues with using binaries where TPI is set (e.g. using without multiple threads)?

No, that should work.