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
I maintain a CDN for Stork's build artifacts, which you can access from https://files.stork-search.net. These build artifacts include the files you can embed from your webpage (like stork.js, stork.wasm, or basic.css), as well as the command line binary. Recently, a few issues have cropped up (#178 and #168) that have shown that my current approach to file organization on the CDN doesn't work.
In this post, I'd like to:
describe changes that I'm making to the file-naming system on the CDN, and
describe the file structure of the CDN, giving you guidance on how to retrieve Stork's build artifacts.
Changes
Starting today, I'm deprecating any URL on the CDN that points to a file named stork-ubuntu-latest or stork-macos-latest. These files are named based on Github Actions' nomenclature; however, that means Stork is tied to the OS version that Github determines is "latest." I want to be (and I want Stork's users to be) explicit about the build that should be downloaded, instead of using whatever ubuntu-latest points to.
Deprecating these URLs means that I will not be updating the files at these URLs, even when I publish a new Stork release. Eventually, once these URLs have not received any HTTP requests for 30 days, I will remove them.
What's on the CDN?
Build artifacts—both command line binaries and web files—are published on the CDN and organized by release. Each release has a directory in files.stork-search.net/releases, and the build artifacts for each release are published in their respective release directory.
There is also a "special" directory in /releases/, named latest/. This directory is an alias to the directory for the most recent release. For example, as I write this, the /releases/1.2.1/ and releases/latest/ directories should have identical contents.
There are also files at the root of the CDN. The files here are mirrors of the build artifacts in /releases/latest, but command line tool binaries are not available on the CDN root.
In practice, this means that today, the following three URLs return the same file:
files.stork-search.net/stork.js
files.stork-search.net/releases/latest/stork.js
files.stork-search.net/releases/v1.2.1/stork.js
Furthermore, the following two URLs return the same file:
However, files.stork-search.net/stork-ubuntu-20-04 does not exist, since command line tool binaries are not available on the CDN root.
Conclusion
Please let me know if you have any questions or thoughts on the directory structure of the CDN. I'm happy to change my thinking here if I've missed something critical or if I'm not accurately representing how people use the CDN.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello!
I maintain a CDN for Stork's build artifacts, which you can access from
https://files.stork-search.net
. These build artifacts include the files you can embed from your webpage (likestork.js
,stork.wasm
, orbasic.css
), as well as the command line binary. Recently, a few issues have cropped up (#178 and #168) that have shown that my current approach to file organization on the CDN doesn't work.In this post, I'd like to:
Changes
Starting today, I'm deprecating any URL on the CDN that points to a file named
stork-ubuntu-latest
orstork-macos-latest
. These files are named based on Github Actions' nomenclature; however, that means Stork is tied to the OS version that Github determines is "latest." I want to be (and I want Stork's users to be) explicit about the build that should be downloaded, instead of using whateverubuntu-latest
points to.Deprecating these URLs means that I will not be updating the files at these URLs, even when I publish a new Stork release. Eventually, once these URLs have not received any HTTP requests for 30 days, I will remove them.
What's on the CDN?
Build artifacts—both command line binaries and web files—are published on the CDN and organized by release. Each release has a directory in
files.stork-search.net/releases
, and the build artifacts for each release are published in their respective release directory.There is also a "special" directory in
/releases/
, namedlatest/
. This directory is an alias to the directory for the most recent release. For example, as I write this, the/releases/1.2.1/
andreleases/latest/
directories should have identical contents.There are also files at the root of the CDN. The files here are mirrors of the build artifacts in
/releases/latest
, but command line tool binaries are not available on the CDN root.In practice, this means that today, the following three URLs return the same file:
files.stork-search.net/stork.js
files.stork-search.net/releases/latest/stork.js
files.stork-search.net/releases/v1.2.1/stork.js
Furthermore, the following two URLs return the same file:
files.stork-search.net/releases/latest/stork-ubuntu-20-04
files.stork-search.net/releases/v1.2.1/stork-ubuntu-20-04
However,
files.stork-search.net/stork-ubuntu-20-04
does not exist, since command line tool binaries are not available on the CDN root.Conclusion
Please let me know if you have any questions or thoughts on the directory structure of the CDN. I'm happy to change my thinking here if I've missed something critical or if I'm not accurately representing how people use the CDN.
Beta Was this translation helpful? Give feedback.
All reactions