Add the possibility to pass additional cmake arguments

[tmadlener]

BEGINRELEASENOTES

• Add the possibility to pass additional cmake arguments to the action

ENDRELEASENOTES

Would allow to simply pass the necessary arguments to download the STL files on the fly for key4hep/k4geo#428

[jmcarcell]

For using this I see two ways each with problems. Modifying the workflow that exists right now is not great because it would get overwritten when there are updates. Creating another workflow with the extra options means that workflow won't get updates automatically when they are applied to all the repositories.

[tmadlener]

Yeah, neither is ideal. Currently when the workflow is updated, the workflows/key4hep-build.yaml is simply copied to all the repositories, right? (btw: is there a script does that? If so, where does that live).

I am wondering how often we have to actually change the workflow file. It's mainly the images at this point, I would assume. The rest will be picked up via changes to the action(?). In principle it would be possible to write a tiny python script that e.g. just updates the images.

I think the action needs to be a bit more flexible as it is now, because otherwise we will have to start changing default build, cmake or test options in packages, simply because the action cannot deal with small differences properly.

[jmcarcell]

Yeah, neither is ideal. Currently when the workflow is updated, the workflows/key4hep-build.yaml is simply copied to all the repositories, right? (btw: is there a script does that? If so, where does that live).

Yes, it's this one https://github.com/key4hep/key4hep-dev-utils/blob/fcc-packages/scripts/sync-files.sh

I am wondering how often we have to actually change the workflow file. It's mainly the images at this point, I would assume. The rest will be picked up via changes to the action(?). In principle it would be possible to write a tiny python script that e.g. just updates the images.

It's updating images or sometimes updating the workflow for some reason. There are not so many changes but I think in the coming weeks there are going to be some changes, maybe the addition of workflows using the stack on LCGCmake so creating an additional workflow in k4geo may just be easier. At least for alma9 there are no updates.

I think the action needs to be a bit more flexible as it is now, because otherwise we will have to start changing default build, cmake or test options in packages, simply because the action cannot deal with small differences properly.

Yes probably, so far the set of tests that one should run locally and on CI have been the same. I don't have any problems with this.

[tmadlener]

Do we have a plan for this sort of functionality? This is blocking key4hep/k4geo#428

[andresailer]

We can set environment variables for actions in each project, so we could pass additional cmake variables from the environment?

[tmadlener]

I think that could work in principle, but it would still mean that we have to change the actions yaml file(?). Or would we go via the actions environment variables? The latter has the potential to become rather opaque to users, as they will not immediately see which variables or to which values they are set unless they look at the logs.

[andresailer]

I think we would have to change the yaml file to allow the use of the variables.

[tmadlener]

But that change could be done centrally. The main concern is that the yaml file should only be changed centrally, and not be touched by individual projects. So there needs to be a way to keep the central version unchanged in the projects to make central distribution possible, yet still be able to customize some parts of the environment downstream.

One other option would be to only use the action downstream, not the full action.yaml.

[andresailer]

Change the action to optionally source a repository local environment file or similar to allow injecting all kinds of changes.