Context
Follow-up while adopting the now-multi-key check-upstream-version-task.yml in ptr727/ESPHome-NonRoot (closing the loop on #168 / #169).
Issue
The task writes the state file with printf '%s\n' "$new" > "$STATE_FILE" on the Ubuntu runner, i.e. LF line endings. But the template's .editorconfig (a verbatim downstream carry) sets:
[*.{json,jsonc}]
end_of_line = crlf
So in a downstream that carries .editorconfig, the committed upstream-version.json (LF, to match the task's output and avoid churn) conflicts with the repo's stated CRLF rule for JSON. If anyone opens the file in an .editorconfig-aware editor and saves it, it flips to CRLF, and the next tracker run rewrites it back to LF - a spurious Canonicalize upstream version state file PR.
It's a narrow case (the file is bot-maintained and rarely hand-edited, and .gitattributes * -text stops git from normalizing), but it bites every CRLF-default downstream that adopts the task.
Options
- Have the task honor the repo's
.editorconfig (e.g. emit CRLF when the state file's configured EOL is CRLF), or
- Document that the state file is canonical LF and carve it out - either an
.editorconfig stanza ([upstream-version.json] end_of_line = lf) shipped with the task, or a .gitattributes upstream-version.json text eol=lf note in the adoption steps.
Option 2 is probably simplest and keeps the task's output deterministic. Whichever you pick, a line in the task's adoption guidance would save the next downstream from rediscovering it.
Context
Follow-up while adopting the now-multi-key
check-upstream-version-task.ymlinptr727/ESPHome-NonRoot(closing the loop on #168 / #169).Issue
The task writes the state file with
printf '%s\n' "$new" > "$STATE_FILE"on the Ubuntu runner, i.e. LF line endings. But the template's.editorconfig(a verbatim downstream carry) sets:So in a downstream that carries
.editorconfig, the committedupstream-version.json(LF, to match the task's output and avoid churn) conflicts with the repo's stated CRLF rule for JSON. If anyone opens the file in an.editorconfig-aware editor and saves it, it flips to CRLF, and the next tracker run rewrites it back to LF - a spuriousCanonicalize upstream version state filePR.It's a narrow case (the file is bot-maintained and rarely hand-edited, and
.gitattributes* -textstops git from normalizing), but it bites every CRLF-default downstream that adopts the task.Options
.editorconfig(e.g. emit CRLF when the state file's configured EOL is CRLF), or.editorconfigstanza ([upstream-version.json] end_of_line = lf) shipped with the task, or a.gitattributesupstream-version.json text eol=lfnote in the adoption steps.Option 2 is probably simplest and keeps the task's output deterministic. Whichever you pick, a line in the task's adoption guidance would save the next downstream from rediscovering it.