Skip to content
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

Have darwin CI store artifacts locally #16

Open
1 task
brryan opened this issue Nov 24, 2024 · 2 comments
Open
1 task

Have darwin CI store artifacts locally #16

brryan opened this issue Nov 24, 2024 · 2 comments

Comments

@brryan
Copy link
Collaborator

brryan commented Nov 24, 2024

The Darwin CI script reports the result of the test run to github, but it does not store any artifacts from the run, which would be useful for diagnosing failures.

I don't know how to send artifacts from Darwin to github. But one possibility would be to have each CI run create a ci_darwin_volta-x86_PR[#]_[slurm job ID] directory in artemis/tst (by default, optionally overwritten) that includes the slurm output file already created, and also all the artifacts created by the testing.

I will get to this after:

@brryan brryan mentioned this issue Nov 24, 2024
3 tasks
@adamdempsey90
Copy link
Collaborator

One other related thing. I don't know what the log file gets us over print statements. The slurm output file has everything we need to diagnose what happened except for some of the logging comments (e.g., density for this test is xx which is outside the tolerance) that could just be normal print statements.

@brryan
Copy link
Collaborator Author

brryan commented Nov 25, 2024

One other related thing. I don't know what the log file gets us over print statements. The slurm output file has everything we need to diagnose what happened except for some of the logging comments (e.g., density for this test is xx which is outside the tolerance) that could just be normal print statements.

I agree in this case the logfile and slurm output should be mostly (but maybe not exactly?) redundant, but that's a special case of the slurm-based workflow, and since in my proposal we'd already be creating a ci_[partition]_pr[#]_[slurm job id] directory it shouldn't cost us anything to just dump the logfile in there as well, which someone may find convenient at some point if they are comparing a slurm run with a non-slurm run_tests.py call

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants