Detect between gitsha and tag

[GretaCB]

When creating a new mason release PR, there is a tricky difference in the mason_load_source
function between gitsha releases and official tag releases.

Similar gotchya related to the build path

• gitsha --> mason_packages/.build/mapbox-vtzero-7adde32
• tag--> mason_packages/.build/vtzero-1.0.0

How can mason perhaps detect this automatically? Or somehow avoid this unknown gotchya?

cc @mapbox/core-tech

[sssoleileraaa]

@GretaCB What is the current process for handling the difference between gitsha releases and tag releases when we try to create a new mason release? Are there some manual steps you've taken to handle the issue?

[springmeyer]

@AllieOop and I took a closer look at this issue.

The workaround, in short, when going from dev release to tagged release is to:

• switch from keyword of tarball in the url path to the keyword of archive in the path (see below for full url examples)
• add a v in front of the ${MASON_VERSION} in the download url
• add a .tar.gz after ${MASON_VERSION} in the download url
• strip the org name off the the MASON_BUILD_PATH (the org name that github puts in the tarball folder name that is unpacked)

But this is totally not obvious! So, we dug deeper...

We noticed that the challenge is that when going from a package pinned to a gitsha to a package pinned to a specific version a couple issues present themselves:

• There are two ways to pull code from github:
  • 🍎 https://github.com/mapbox/protozero/tarball/
  • 🍏 https://github.com/mapbox/protozero/archive/
• The 🍎 (dev way) is how we usually pull specific gitshas.
• The 🍏 (archive way) is how we usually pull a tagged version

We were interested if we could also use the 🍎 (dev way) to also pull a tagged version.

Our experiment was:

• Given the tagged version is 1.6.2 and gitsha is d5d8deb:
  • When requesting a tagged version from 🍎 you can ask for tarball/v1.6.2
  • When requesting a gitsha from 🍎 you can ask for tarball/d5d8deb

The problem with this approach is:

• MASON_VERSION does not contain the v

This is what we came up with (which we will refer to in further debugging):

diff --git a/scripts/protozero/1.6.2/script.sh b/scripts/protozero/1.6.2/script.sh
index e8c0e0a..cbf2d0f 100644
--- a/scripts/protozero/1.6.2/script.sh
+++ b/scripts/protozero/1.6.2/script.sh
@@ -8,12 +8,12 @@ MASON_HEADER_ONLY=true
 
 function mason_load_source {
     mason_download \
-        https://github.com/mapbox/protozero/archive/v${MASON_VERSION}.tar.gz \
-        6c9cc925fc9aee4285d5bd489c2f3978a3d66b84
+        https://github.com/mapbox/protozero/tarball/v${MASON_VERSION} \
+        ddced4a77bffe0d1d0794c1a4334d0d3fe9d1b29
 
     mason_extract_tar_gz
 
-    export MASON_BUILD_PATH=${MASON_ROOT}/.build/protozero-${MASON_VERSION}
+    export MASON_BUILD_PATH=${MASON_ROOT}/.build/mapbox-protozero-${MASON_VERSION}
 }
 
 function mason_compile {

[GretaCB]

Great digging! I'll refer to this when publishing the official v1.0.0 release of gzip-hpp