Open GretaCB opened 6 years ago
@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?
@allieoop and I took a closer look at this issue.
The workaround, in short, when going from dev release to tagged release is to:
tarball
in the url path to the keyword of archive
in the path (see below for full url examples)v
in front of the ${MASON_VERSION}
in the download url.tar.gz
after ${MASON_VERSION}
in the download urlorg
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:
https://github.com/mapbox/protozero/tarball/
https://github.com/mapbox/protozero/archive/
We were interested if we could also use the 🍎 (dev way) to also pull a tagged version.
Our experiment was:
1.6.2
and gitsha is d5d8deb
:
tarball/v1.6.2
tarball/d5d8deb
The problem with this approach is:
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 {
Great digging! I'll refer to this when publishing the official v1.0.0 release of gzip-hpp
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
mason_packages/.build/mapbox-vtzero-7adde32
mason_packages/.build/vtzero-1.0.0
How can mason perhaps detect this automatically? Or somehow avoid this unknown gotchya?
cc @mapbox/core-tech