-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changed Docker image for GitLab CI pipeline, cmake tweaks #111
Conversation
Pipeline is faling, I guess we should fix the cmake to find Gardfield. |
I did a work around to avoid the Garfield cmake error, it worked but the pipeline still failing, looks like a compilation error. |
I think I have fixed this issue, the problem with Garfield is solved but it breaks backwards compatibility with older versions of Garfield due to classes having been renamed. I think its fair to drop this old version (~5 years old) and stick with the "new" one. I guess we could maintain backwards compatibility with clever use of macros, if someone wants to make a commit. The way Garfield is linked now is not the prettiest one, in fact, its pretty ugly. I tried to do it properly but couldn't due to the complex structure of our build. I think its time to refactor the cmake code. I will do this down the line. Also in this PR we changed the CI Docker image to a newer one. This is the image I use for development and so far it has worked pretty well. I have automated the production of new tags so I can get a different C++ standard / ROOT or Geant4 version without much effort. |
Now the pipeline has failed due to a dictionary problem. I will try to fix it. The problem seems to be in connectors lib, I can't find a solution so far, perhaps @jgalan has some ideas? |
I have seen that problem before, but not 100% sure of what it is the origin. Perhaps it is in fact that Garfield Hope that helps. Perhaps @nkx has also some ideas. |
… (perhaps not on some VERY old installations)
…UTABLE to fix -f bug
…ck in GitLab actions. (but why doesn't this happen elsewhere)
It looks like commit 01f7d13 fixed the pipeline issue. In this commit I added a flag (-q) to quit instead of launching the root REPL. In principle this should not be needed, as the -q flag should be understood without explicitly defining it, and this seems to be the case up until now. For some reason on the GitLab job this fails, but not when testing it manually on the Dockerfile. I have no idea why this is the case but this commit fixes it. I don't think this has any side-effects. |
source/bin/restRoot.cxx
Outdated
@@ -16,7 +16,6 @@ int main(int argc, char* argv[]) { | |||
setenv("REST_VERSION", REST_RELEASE, 1); | |||
|
|||
Int_t loadMacros = 0; | |||
bool quit = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why coming back to previous implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't work when you run macros :( restRoot -q Macro.C
.
…ramework into gitlab-ci-dockerimage
Update image version
New image uses more recent build tools such as cmake 3.16 which is needed by #109. It should work as the previous one.