You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using chmod every time after unpacking the updated zip file is annoying. By using a decent file format like tar.gz or tar.bz2, that would not be necessary.
The text was updated successfully, but these errors were encountered:
Good point -- I used zip because it is "natively" supported on windows (and I recall the API to write zip files is more pleasant). Also, doing bash run.sh instead of ./run.sh doesn't seem too bad.
On the other hand, any Windows developers using go probably have some kind of MinGW / Cygwin situation, which would provide them with tar as well.
I am deploying all my stuff using systemd, where you specify an absolute path to the binary you want to run. In my case that is /opt/piksku/run.sh, which is much clearer than /usr/bin/bash /opt/piksku/run.sh.
Another thing I’ve noticed is that the timestamps of the files are all wrong (e.g. "-rw-r--r-- 1 root root 482 1985-08-14 00:00 app.conf"). Is that an oversight or another implication of using zip files? It might be bad for the Last-Modified HTTP mechanism, e.g. when you edit a file on the production server (it’s a no-no, but people probably still occasionally do it), then later edit it locally with different changes and deploy a new package. The client would not get the new file in that situation.
Using chmod every time after unpacking the updated zip file is annoying. By using a decent file format like tar.gz or tar.bz2, that would not be necessary.
The text was updated successfully, but these errors were encountered: