Linux workflow build

[ArsenP0doba]

Hello, my name is Arsen. I’m from SoftSolution, and we want to contribute to QuantLib and QuantLib-SWIG. My issue is that I made some changes in the SWIG/*.i files, and when I push the changes to a forked repository, the Linux workflow fails because the QuantLib version installed on the CI runner doesn’t include my changes yet. Should I update the workflows to build against my QuantLib fork ?

[boring-cyborg]

Thanks for posting! It might take a while before we look at your issue, so don't worry if there seems to be no feedback. We'll get to it.

[lballabio]

Hello, Arsen. Let me see if I get it correctly: you would like the workflow in the forked QuantLib-SWIG repository to run inside Docker images containing changes that are in your QuantLib fork but not yet in mine, right?

[ArsenP0doba]

Yes, you are correct.

[lballabio]

Hmm, ok. I would have to parameterize the workflow but leave the current default (which is ok for most forks). I'll have a look.

[ArsenP0doba]

Ok, thanks for the quick response.

[RobertoSoft]

hi @lballabio Roberto here. I'm working w Arsen and our goal is to validate the QL+SWIG build before we make a MR. Am I understanding this correctly? aka Docker is used for SWIG build only. Also, any docker image(s) to validate Windows & Linux builds? Sorry for the silly questions... Maybe there is a link to a "How to"?
Roberto

[lballabio]

Hi Roberto, Docker is used for a number of Linux builds both for SWIG here and for the main library. The main library is also built on Windows and MacOS in other workflows, but without Docker. We don't have an automated Windows build for QL-SWIG, but it's not been a problem so far. The wrappers are pretty portable, and if they work on Linux they usually work on other platforms as well.

Until now, I guess contributors making changes in both C++ and SWIG would build them locally. As for automated builds here on GitHub, they usually open the C++ PR in the main repo, check the builds there, and then wait for me to merge their changes and update the Docker images for the SWIG build, at which point they open the SWIG PR in this repo.

Arsen's suggestion is better :) I'm looking into modifying the workflows so that you can build and use your own images.

[RobertoSoft]

@lballabio we want to send you a MR re our changes, both in C++ & SWIG. what do U suggest?

1. We do the MR with the SWIG chgs failing (due to the docker issue)
2. We fix ourselves the docker issue (any tips/pointers?)
3. We wait?
   ty
   Roberto

[lballabio]

I'd suggest to go ahead and open both PRs.