Scenario
Using zip-build in a GitHub action to create a file which will be included as (part of?) an artifact. The filename needs to include a timestamp.
Problem
The Github actions upload-artifact rejects the filename because it contains colons. Reason stated: because some actions run on NTFS, colons are disallowed in artifact files.
actions/upload-artifact#546
Workaround
In npm runscript, it's possible to avoid the use of %TIMESTAMP and use something like $(date +%F:%H-%M-%S) instead. This relies on Unix shell interpolation, however, and is not cross-platform.
References
A previous fix here detects the OS which is running at the time of creation, and automatically avoids colons if the OS is Windows / NT.
#4
However, this cannot address this general problem where the zip is generated on some other OS, but needs to be stored on (say) NTFS.
Caveats
GH upload-action zips all the content of the artifact anyway, so zip-build is potentially superfluous here.
And other actions may not have the colon constraint.
Nevertheless, I'm referring to more of a category of situations where the output file created by zip-build may end up on a colon-intolerant situation, such as an NTFS filesystem. So I think this is a more widely valid problem for zip-build users than the specific case I encountered it.
Potential Solutions
A general resolution can't simply check the OS at runtime. It needs to allow the user invoking zip-build to trigger a colon-free timestamp, perhaps using a flag or parameter?
Also: there may be other characters in timestamps which need to be avoided, for instance periods. I don't have this specific problem, but it may be a more general consideration.
Some potential solutions in the link below allow the kind of workaround I used, but within zip-build functionality. As opposed to pushing it upstream to shell interpolations or some other external formatter, which puts the burden back on the user, making zip-build much less of a no-brainer.
https://stackoverflow.com/questions/10645994/how-to-format-a-utc-date-as-a-yyyy-mm-dd-hhmmss-string-using-nodejs
Most of them would require an extra dependency, although this answer includes a small function which could be inlined. Opinions differ about whether this is a good or bad solution.
Scenario
Using zip-build in a GitHub action to create a file which will be included as (part of?) an artifact. The filename needs to include a timestamp.
Problem
The Github actions
upload-artifactrejects the filename because it contains colons. Reason stated: because some actions run on NTFS, colons are disallowed in artifact files.actions/upload-artifact#546
Workaround
In
npmrunscript, it's possible to avoid the use of%TIMESTAMPand use something like$(date +%F:%H-%M-%S)instead. This relies on Unix shell interpolation, however, and is not cross-platform.References
A previous fix here detects the OS which is running at the time of creation, and automatically avoids colons if the OS is Windows / NT.
#4
However, this cannot address this general problem where the zip is generated on some other OS, but needs to be stored on (say) NTFS.
Caveats
GH upload-action zips all the content of the artifact anyway, so zip-build is potentially superfluous here.
And other actions may not have the colon constraint.
Nevertheless, I'm referring to more of a category of situations where the output file created by zip-build may end up on a colon-intolerant situation, such as an NTFS filesystem. So I think this is a more widely valid problem for
zip-buildusers than the specific case I encountered it.Potential Solutions
A general resolution can't simply check the OS at runtime. It needs to allow the user invoking
zip-buildto trigger a colon-free timestamp, perhaps using a flag or parameter?Also: there may be other characters in timestamps which need to be avoided, for instance periods. I don't have this specific problem, but it may be a more general consideration.
Some potential solutions in the link below allow the kind of workaround I used, but within
zip-buildfunctionality. As opposed to pushing it upstream to shell interpolations or some other external formatter, which puts the burden back on the user, makingzip-buildmuch less of a no-brainer.https://stackoverflow.com/questions/10645994/how-to-format-a-utc-date-as-a-yyyy-mm-dd-hhmmss-string-using-nodejs
Most of them would require an extra dependency, although this answer includes a small function which could be inlined. Opinions differ about whether this is a good or bad solution.