-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
FWIW just 1c: know that scriv is used, and breaking changes "brake things" #82
Comments
Hi, I certainly don't intend to break things. I'm not sure what version you were using, and what version you upgraded to? What was your configuration? Can you provide more information so I can understand better? What is the full error report? |
Hi Ned. Sorry I was too brief - I was suffering from "I touched the damn laptop during the weekend for a quick 'Just to press this button to merge this PR' and then it sucked me in...". I will try to refrain from such actions in the future for both of our sake ;) TL;DR: I think that the change in 1.1.0 — 2023-01-16 "File names specified for file: settings will be interpreted relative to the current directory if they have path components. If the file name has no slashes or backslashes, then the old behavior remains: the file will be found in the fragment directory, or as a built-in template." is the one which broke our workflows. Our generalized setup across repos is to have
and which collects changelog snippets until then release workflow runs
We use e.g. Jan 16th we got a release cooked, log is here and it had
and we got release produced. Yesterday workflow failed in datalad-container, full log with
and we had already
which supports my identification of culprit in TL;DR above identified from the CHANGELOG. I had to patch up our scriv.ini in |
OK, thanks. As of commit 530c9de, all file paths are looked for in the fragments directory, and then in the current directory, and then as a builtin template. UNLESS the first file path component is |
This is now released as part of scriv 1.2.1. |
As we started to use
scriv
more and established our "scriv-based" release workflow across datalad extensions , a failed release came as a surprise due toscriv.exceptions.ScrivException: No such file: templates/entry_title.md.j2
.IMHO adding such new semantic while breaking existing workflows is suboptimal. If there was need to enable some new setups/relative paths, some new syntax, less likely to be used (e.g. paths started with
./
or specialfile:///
URI protocol specification) might have been better.The text was updated successfully, but these errors were encountered: