Description
Every conda lock file served via /v1alpha1/builds/{buildId}/condalock (and therefore every .conda-lock/*.txt committed by nf-core modules containers create) starts with a stray leading blank line before its real content, e.g.:
version: 6
environments:
default:
...
Confirmed present in every lock file currently in nf-core/modules built through this path (fastqc, multiqc, busco, and the pixi-based bismark bump in nf-core/modules#12356).
Root cause
BuildLogServiceImpl.extractCondaLockFile():
protected static String extractCondaLockFile(String logs) {
int start = logs.lastIndexOf(CONDA_LOCK_START)
int end = logs.lastIndexOf(CONDA_LOCK_END)
if( start >= end ) {
return null
}
return logs.substring(start + CONDA_LOCK_START.length(), end)
.replaceAll(/#\d+ \d+\.\d+\s*/, '')
}
The Dockerfile/Singularityfile templates wrap the lock file with:
&& echo ">> CONDA_LOCK_START" \
&& cat pixi.lock \
&& echo "<< CONDA_LOCK_END"
In the raw BuildKit log, each line carries a #N T.T prefix, e.g.:
#8 1.234 >> CONDA_LOCK_START
#8 1.235 version: 6
#8 1.236 environments:
...
logs.substring(start + CONDA_LOCK_START.length(), end) starts right after the >> CONDA_LOCK_START text but before that log line's own trailing newline. Every following line's #N T.T prefix gets stripped by the regex, but that first newline was never preceded by a prefix, so it survives untouched as a leading blank line in the extracted content.
Reproduced by feeding a synthetic BuildKit log through the same extraction logic (Python re equivalent of the Groovy regex):
>>> extract(...)
'\nversion: 6\nenvironments:\ndefault:\n'
Note the existing test BuildLogsServiceTest.groovy ('should extract conda lockfile') actually asserts this leading blank line as the expected output today — it was written to match the current (buggy) behavior rather than to catch it.
Suggested fix
Strip the leading whitespace after the existing regex pass, e.g.:
return logs.substring(start + CONDA_LOCK_START.length(), end)
.replaceAll(/#\d+ \d+\.\d+\s*/, '')
.stripLeading()
Happy to open a PR with this fix plus an updated/added test if useful.
Description
Every conda lock file served via
/v1alpha1/builds/{buildId}/condalock(and therefore every.conda-lock/*.txtcommitted bynf-core modules containers create) starts with a stray leading blank line before its real content, e.g.:Confirmed present in every lock file currently in nf-core/modules built through this path (fastqc, multiqc, busco, and the pixi-based bismark bump in nf-core/modules#12356).
Root cause
BuildLogServiceImpl.extractCondaLockFile():The Dockerfile/Singularityfile templates wrap the lock file with:
In the raw BuildKit log, each line carries a
#N T.Tprefix, e.g.:logs.substring(start + CONDA_LOCK_START.length(), end)starts right after the>> CONDA_LOCK_STARTtext but before that log line's own trailing newline. Every following line's#N T.Tprefix gets stripped by the regex, but that first newline was never preceded by a prefix, so it survives untouched as a leading blank line in the extracted content.Reproduced by feeding a synthetic BuildKit log through the same extraction logic (Python
reequivalent of the Groovy regex):Note the existing test
BuildLogsServiceTest.groovy('should extract conda lockfile') actually asserts this leading blank line as the expected output today — it was written to match the current (buggy) behavior rather than to catch it.Suggested fix
Strip the leading whitespace after the existing regex pass, e.g.:
Happy to open a PR with this fix plus an updated/added test if useful.