Fetch script now downloads script to execute #139
Conversation
These scripts will become the source of truth and will be downloaded by the new fetch scripts
…ript With this change, we can now update the actual fetch script used by all tracks in a single location
|
At some point, it would be good to add a test too to verify that the |
Indeed. Let's keep track of that in #121 |
Co-authored-by: ee7 <45465154+ee7@users.noreply.github.com>
Co-authored-by: ee7 <45465154+ee7@users.noreply.github.com>
Yeah me neither. I'm open for suggestions |
|
This PR seems to be controversial after having spoken to some people, so I'll close this PR. The strategy will instead be to automatically send PRs to tracks to update. |
Sounds reasonable. I was gradually leaning that way too. I had this reservation: the "fetch-fetch" approach is only a win overall if the "fetch-fetch" script needs updating less often than the plain fetch script. But the "fetch-fetch" approach is less mature and has had fewer eyes on it, so it's likely to require updates if it has any complexity at all, and some complexity is arguably merited. |
|
|
||
| rm -f "${output_path}" | ||
| # Execute the fetch script | ||
| bash -c "${script}" |
There was a problem hiding this comment.
Could exec bash -c "${script}" here to replace the running process. That's (kind of) the shell's "tailcall" mechanism.
There was a problem hiding this comment.
Great feedback, thanks. Sorry for the slow reply - still catching up on notifications.
We decided to stick with the fetch-configlet status quo for now, but I imagine we'll use your suggestion if we revisit the "fetch-fetch-configlet" idea.
|
Well, it doesn't have "script" in the filename, so I like it :) I guess I think the clearest naming was |
For the background/motivation, see: #181