Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag usage in newer rebar3 versions #2846

Open
tothlac opened this issue Nov 16, 2023 · 14 comments
Open

Tag usage in newer rebar3 versions #2846

tothlac opened this issue Nov 16, 2023 · 14 comments

Comments

@tothlac
Copy link
Contributor

tothlac commented Nov 16, 2023

We use tags like 3.13.3 for our main versions, and sometimes when there is a problem on the production server we release a hotfix. We tag it as 3.13.3.1, then 3.13.3.2, etc.

It was working in older versions of rebar3 (3.13.x), in newer versions (3.18.0) I got an error when I run

rebar3 relup --relname myapp --relvsn 3.13.3.1

I got this:

===> Uncaught error in rebar_core. Run with DIAGNOSTIC=1 to see stacktrace or consult rebar3.crashdump
===> Uncaught error: function_clause
===> Stack trace to the error location:
[{rlx_util,parsed_vsn_lt,
           [0,0],
           [{file,"/Users/tothlac/otp/rebar3/_build/default/lib/relx/src/rlx_util.erl"},
            {line,82}]},
 {rlx_util,parsed_vsn_lte,2,
           [{file,"/Users/tothlac/otp/rebar3/_build/default/lib/relx/src/rlx_util.erl"},
            {line,80}]},

Let's suppose I already have created 3.13.4, so I can't use that tag for the hotfix release. I've also tried to use 3.13.3-hotfix for the target, but that also fails.

What would you advice? What tag should I use for the hotfix which works in these newer rebar3 versions?

I got the error using this script:

cat ~/upgrade.sh
#!/bin/bash

set -ex

APP_NAME=$1
BASE_VERSION=$2
TARGET_VERSION=$3

export BUILD_ENV=sit

git reset --hard $BASE_VERSION
rebar3 as prod tree
rebar3 --version
rebar3 as prod release
rebar3 as prod tar

git reset --hard $TARGET_VERSION 
rebar3 as prod release
rebar3 --version
DEBUG=1 rebar3 as prod relup --relname $APP_NAME --relvsn $TARGET_VERSION
@tothlac
Copy link
Contributor Author

tothlac commented Feb 28, 2024

Hi. Is there an update on this problem?

We were trying to find a solution using tags consisting of only 3 numbers but unfortunately it wont solve our problem. We need to tag hotfixes with 4 numbers or with some postfix following the third number. As mentioned above none of these two options work. Do you think its a valid problem which should be addressed or can you see any other possible solution?

@ferd
Copy link
Collaborator

ferd commented Feb 28, 2024

No updates.

I've cut back some of my maintaining time for OSS stuff as I'm doing other things in my life (and also side projects that aren't just builds), and as such I've tackled generally blocking bugs or compatibility issues across Erlang versions, but I don't have the bandwidth to do deeper overhauls within the tooling.

The apparent thing is that relx started only supporting semver somewhere in 2020 as part of its 4.0 version, which we introduced in Rebar3 3.14.0 back in August 2020. These fixes to go for semver were made as part of some refactorings to properly sort versions while trying to support systools updates that happened back then.

At this point I'm not really sure what is safe or not to do, or how we could do comparison of non-semver versions with semver versions if we were to support both; the change has been there for a long enough time that undoing it is its own risk as well, so it's not a simple change for sure.

@tsloughter
Copy link
Collaborator

You can put basically anything after a + can't you?

@tothlac
Copy link
Contributor Author

tothlac commented Mar 1, 2024

No, unfortunately using a tag like 0.1.0+build1 is not possible. Using rebar3 3.22.1 it fails with

===> Upfrom release version (0.1.0+build1) for relup not found

even though the release has been generated for that tag

tothlac:oyhveyh find . -name 0.1.0+build1
./_build/default/rel/oyhveyh/releases/0.1.0+build1
./.git/refs/tags/0.1.0+build1
tothlac:oyhveyh
tothlac:oyhveyh ls ./_build/default/rel/oyhveyh/releases/0.1.0+build1
no_dot_erlang.boot	start.script		vm.args
oyhveyh.rel		start_clean.boot
start.boot		sys.config

@tothlac
Copy link
Contributor Author

tothlac commented Mar 1, 2024

tothlac:oyhveyh rebar3 --version
rebar 3.22.1 on Erlang/OTP 26 Erts 14.2.1

@tothlac
Copy link
Contributor Author

tothlac commented Mar 1, 2024

I've pushed a repository here, where it does not work: https://github.com/tothlac/oyhveyh/
I've used this script to reproduce the error:

tothlac:oyhveyh cat ~/work/upgr.sh
#!/bin/bash

set -ex

APP=$1
BASE=$2
TARGET=$3

printf "Upgrade on %s between versions %s ==> %s\n" ${APP} ${BASE} ${TARGET}

rm -rf _build
git reset --hard ${BASE}
rebar3 release

git reset --hard ${TARGET}
rebar3 release
rebar3 appup generate
rebar3 relup --relname ${APP} --relvsn ${TARGET}

then I called

../upgr.sh oyhveyh 0.1.0 0.1.0+build1

It works with target tag 0.1.1, but does not work with 0.1.0+build1 because I got the above mentioned problem

@tsloughter
Copy link
Collaborator

Oh, is this only an issue for relups?

@tsloughter
Copy link
Collaborator

You say it is "newer rebar3" tho, did using such version tags used to work?

@tsloughter
Copy link
Collaborator

Sorry, why did I not reread the origin post, haha.

I see it is two separate issues for using 4 digits and using +build1.

The latter is possibly a systools issue since it is an issue in relups. I need to check where that error message comes from.

@tsloughter
Copy link
Collaborator

Ok, it is a bug in relx_relup it appears. I don't know why get_version_before fails. But this should definitely be fixable and I'll look into it more.

@tothlac
Copy link
Contributor Author

tothlac commented Mar 4, 2024

Actually either tags containing four numbers (4.2.1.10) or three numbers + something at the end like 4.2.1+build1 would be good for us. Unfortunately 3 numbers is not enough for us, we would like to use something after the third number.

I've just tried it with 4.2.1-build1, but that one also does not work, even though:

tothlac:oyhveyh ls _build/default/rel/oyhveyh/releases/
0.1.0		0.1.0-build1	RELEASES	start_erl.data

@tothlac
Copy link
Contributor Author

tothlac commented Mar 4, 2024

I got this:

tothlac:oyhveyh ../upgr.sh oyhveyh 0.1.0 0.1.0-build1
+ APP=oyhveyh
+ BASE=0.1.0
+ TARGET=0.1.0-build1
+ printf 'Upgrade on %s between versions %s ==> %s\n' oyhveyh 0.1.0 0.1.0-build1
Upgrade on oyhveyh between versions 0.1.0 ==> 0.1.0-build1
+ rm -rf _build
+ git reset --hard 0.1.0
HEAD is now at d01dff0 Add appup plugin
+ rebar3 release
===> Fetching rebar3_appup_plugin (from {git,"https://github.com/lrascao/rebar3_appup_plugin.git",
                               {branch,"master"}})
===> Fetching bbmustache v1.5.0
===> Fetching string_compat v0.0.1
===> Analyzing applications...
===> Compiling string_compat
===> Compiling bbmustache
===> Compiling rebar3_appup_plugin
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling oyhveyh
===> Assembling release oyhveyh-0.1.0...
===> Release successfully assembled: _build/default/rel/oyhveyh
+ git reset --hard 0.1.0-build1
HEAD is now at 87ca560 Add cowboy
+ rebar3 release
===> Verifying dependencies...
===> Fetching cowboy v2.11.0
===> Fetching cowlib v2.12.1
===> Fetching ranch v1.8.0
===> Analyzing applications...
===> Compiling cowlib
===> Compiling ranch
===> Compiling cowboy
===> Analyzing applications...
===> Compiling oyhveyh
===> Assembling release oyhveyh-0.1.0-build1...
===> Release successfully assembled: _build/default/rel/oyhveyh
+ rebar3 appup generate
===> current base dir: "/Users/tothlac/work/oyhveyh/_build/default"
===> app oyhveyh ebin dir: "/Users/tothlac/work/oyhveyh/_build/default/lib/oyhveyh/ebin"
===> Generated appup ("0.1.0" <-> "0.1.0-build1") for oyhveyh in "/Users/tothlac/work/oyhveyh/_build/default/lib/oyhveyh/ebin/oyhveyh.appup"
+ rebar3 relup --relname oyhveyh --relvsn 0.1.0-build1
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling oyhveyh
===> Assembling release oyhveyh-0.1.0-build1...
===> Release successfully assembled: _build/default/rel/oyhveyh
===> Upfrom release version (0.1.0-build1) for relup not found

@tothlac
Copy link
Contributor Author

tothlac commented Mar 19, 2024

Do you have any updates on this?

@ferd
Copy link
Collaborator

ferd commented Mar 25, 2024

No updates at this point in time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants