Use shorter `build_key`

[nkaretnikov]

Fixes #611.

[netlify[bot]]

✅ Deploy Preview for kaleidoscopic-dango-0cf31d canceled.

Name	Link
🔨 Latest commit	36da8f04e00674b25241ad06e958420148209a4f
🔍 Latest deploy log	https://app.netlify.com/sites/kaleidoscopic-dango-0cf31d/deploys/6565c0c56f5375000822bf08

[nkaretnikov]

TODO:

• [x] Add build_key_version to Build ORM

  • Envs work by constructing URLs based on build_key. These are then mapped to the state/storage dirs without checking whether the files are there. Active env switching is done via symlinking, which is atomic, also without checking. All this is fine and actually the right thing to do (to avoid TOCTOU issues). However, to make sure that access to old files is not lost via the web UI, it'll be necessary to mark old builds as such and store it in the DB for all builds before this commit (via a migration). All builds after this commit should use a new build version, which would allow distinguishing which build_key version to use for lookup.

• [x] An API test for this:

  • create v1 build (legacy build key) by explicitly setting the version field
  • attempt to access a file, such as http://localhost:8080/conda-store/api/v1/build/1/yaml/ which is accessed via Show yml file in the UI. this will redirect to full path in storage using the build key
  • check that the number of dashes in its build key is the same as v1 (URL that the yaml URL above redirects to)
  • check that the request returns 200 and the output starts with the word "channels:"
  • do the same with the v2 build (new build key), the number of dashes should be different

• [x] A unit test for this:

  • test that build_key works with different Build versions
  • test that parse_build_key parses build id correctly with build keys from different build versions.

[nkaretnikov]

Seems fine. Still need to do the final review and test locally.

[nkaretnikov]

Manual tests I did (as of commit 738f650):

• [x] conda-store state created on main works with changes in the PR (links to the lock file and other files work in the UI)
• [x] having build_key_version=1 in the config allows to access v2 files in the UI
• [x] having build_key_version=2 in the config allows to access v1 files in the UI
• [x] having build_key_version=3 in the config raises an error.

[nkaretnikov]

This is currently blocked due to an upstream test hanging (or taking too long?) (unrelated to this PR): https://github.com/conda-incubator/conda-store/issues/666

I'll try to fix the upstream issue first before opening this for review.

Do not get misled by "All checks have passed" here. The problematic test was skipped.

[nkaretnikov]

@jaimergp Updated, PTAL. Added a command-line/config parameter, now users can switch between v1 and v2 if needed. By default the short hash version is used. With the new default, old environments are still accessible in the UI.

[nkaretnikov]

@jaimergp Addressed your feedback, PTAL

[nkaretnikov]

@jaimergp PTAL. Replied to all of your comments. Only made a change to the docs.