-
Notifications
You must be signed in to change notification settings - Fork 20
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
spack in interior container fails when sourcing setup script or when running any spack command #17
Comments
Hi @frankwillmore, thanks for giving it a try. I'm curious if this is happening when running the spack-infrastructure setup or in your own instance of gitlab? At any rate, this .gitlab-ci.yml hasn't been merged yet, but that repo will be a better starting point. The errors you pasted make me wonder if that really is spack 0.14, as |
@scottwittenburg This is with gitlab/gitlab-ee:12.1.0-ee.0 as specified in the docker-compose, I didn't change anything there. I edited the .gitlab-ci.yml to clone and check out different versions of spack (including the 0.14.0 tag), but wasn't able to run spack --version or source the setup-env.sh for any of them. I I'm running docker desktop 2.2.0.0 on MacOS 10.15.3. |
This is because the docker container has to run with no entrypoint, due to how Gitlab runner works with docker image. The version of Spack under You should be able to clone and use a newer version, though. All you'd need to do is set Failing the above, can you post your |
Thanks @opadron, you're right that's an old image and probably shouldn't be used anymore. The branch on the repo I linked above ( I'm currently trying out the workflow in this repo to see if it's still working the way it is documented in |
Oh, and I just remembered that spack |
So I just ran through the README, starting from a clean slate, and found that with a couple exceptions, the workflow is mostly working fine. I created #18 to reflect the issues I found. Here are the two files which worked for me: The
And the
And with that, I was able to run a pipeline reporting to CDash, uploading binaries to the minio S3 bucket, etc... And for the custom spack I set
|
Actually, I wonder if I should update the README to actually specify the content of those two files, rather than assuming some other repo has up-to-date examples? |
Below is what I get while using the docker-compose.yml from commit 813df65 (latest), and the gitlab-ci.yml that Scott just posted. Now I see the below stacktrace:
|
Are you following the instructions in |
Also regarding the stack traces you're pasting: are you getting those from the gitlab job output terminal? |
Progress! Yes, I've been following the instructions in gitlab-docker/README.md and only deviated in an effort to troubleshoot after seeing failures. I've since torn it all down and started fresh using the .gitlab-ci.yml and spack.yaml above. I would second inlining these with the directions so as to maintain a working snapshot. I have been and am currently setting the values of SPACK_REPO and SPACK_REF to https://github.com/spack/spack.git and v0.14.0, respectively. And yes, I am cutting and pasting from the gitlab job output terminal. Currently it appears to be installing spack and sourcing the setup-env.sh correctly. The job now appears to fail reading a URL (see below). Also, I notice that there are two variables CI_COMMIT_REF_NAME and CI_COMMIT_SHA referenced in the gitlab-ci.yml but I don't have values for them or otherwise see being set.
|
I'm still not clear what was causing the initial problems you reported. I mean, it seems to have been the wrong version of spack compared to what you intended ( Also, in spack
Thanks for clarifying.
You can echo CI_COMMIT_REF_NAME and CI_COMMIT_SHA from your gitlab job (script section) if you want to make sure gitlab is setting them for you. They're used in the auto-generated commit message (going away soon thanks to a feature we've eagerly anticipated !) and in picking part of the name of the branch to push to.
This is where we're trying to push the generated commit to a different branch on the
The stuff above makes it look like the jobs were staged at least, we just need to figure out why it can't be pushed. |
Okay, I had a \n at the end of SPACK_REPO, shame on me. Tore down again and I'm now able to get as far as spack generating and starting the CI stages, but one of the jobs fails in stage 0, and later stages are skipped. Also, CDash is not getting any results.
|
Thanks for sticking with it. I see the spack you're getting has the sha Anyway, then one way to see what actually went wrong (because CDash isn't yet getting results in your case) you can browse to the artifacts and view the |
It just landed. Where can I find pipeline.log? |
OK, found it. I hadn't started minio and the log seemed to complain that it couldn't connect to it so I started it and created 'spack-public' bucket and now it complains it can't find the object. Also, still nothing showing in CDash.
|
There's something in the The error you mentioned about not being able to find the object is just printing out the error that lead to not being able to find that particular |
I had to go back and check 'public dashboard', authenticate submissions was unchecked. CDash shows only the job that doesn't build (pcre2-10.31). How do I view what what built? There's no longer directions for checking builds via the nginx portal. I started the nginx container but it just shows an empty directory. Also, still reporting failure connecting to minio:
It seems to only be affecting pcre2-10.31. I edited and re-ran my-vars.sh and restarted minio and gitlab with the values for minio but nothing changed. All of the stage one jobs finish except for pcre2-10.31. |
Ah right, I forgot which option it was. But at least the instructions mentioned it.
CDash should show you all the jobs. Could some jobs have finished successfully before CDash reporting got enabled or started working? Generally speaking, if the pipeline runs and a spec is already up to date in the mirror, it doesn't need to be rebuilt, and in that case nothing will get reported to CDash.
Nothing is getting pushed into the file system mirror anymore, so the nginx container won't help.
It seems here maybe the
If you want to trigger everything to build again from scratch (and hopefully see all the results in CDash now that it's configured correctly), you can just delete everything from your binary mirror and run the pipeline again. There's an option in the minio interface to remove stuff, just remove the entire |
When running build pipeline prototype using demo configuration, spack fails and generates a python traceback when sourcing setup-env.sh or running e.g. spack --version. The spack.yaml is never processed.
Also, /opt/spack/bin/spack is not included in the PATH when the container is run.
I am starting from the .gitlab-ci.yml at:
https://github.com/scottwittenburg/sc2019-tutorial-pipeline/blob/master/.gitlab-ci.yml
The pipeline fails even with both the version in /opt/spack or with a freshly cloned copy of v0.14.0.
. /opt/spack/share/spack/setup-env.sh
/opt/spack/bin/spack --version
The text was updated successfully, but these errors were encountered: