Bug fix for binding JS_PIPELINE_PATH differences between run and pipelines #164
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes the handling of JS_PIPELINE_PATH within the slurm_singularity backend, namely due to the fact that
jetstream run
does not setJS_PIPELINE_PATH
at runtime unless--pipeline
is defined. The slurm_singularity backend was assuming that this value was always populated and would attempt to bind it by default within singularity.Now, we check to see if
JS_PIPELINE_PATH
is in the environment and handle the export accordingly. Additionally, this PR adds in some bash variable expansion as well as replacingJS_PIPELINE_PATH
with__pipeline__.path
when necessary (within functions such asmd5
). Variable expansion is viaos.path.expandvars()
, and sinceJS_PIPELINE_PATH
doesn't exist in the environment until runtime, we pass the pipeline context to themd5
function.Finally, this also has adjustments for finding containers/images that are already in the cache dir. We previously only found images if the
digest
was defined for the task. Technicallydigest
is an optional, but recommended directive. So now we search the cache dir within the job submission before attempting to pull externally. Theoretically, we should always find the image in the cache, but it's possible the cache has been cleaned since the start of the project and we want to avoid failures in these cases if possible.