Discrepancies between two versions of the start_erl.data

[joshchernoff]

Steps to reproduce

Not 100% sure since our deployment process is complex.

Just a brief list of the steps required to produce the issue. I'm seeing a discrepancy between the two start_erl.data files.

/opt/my_app/releases/start_erl.data shows correctly /opt/insights/var/start_erl.data has a git commit sha that is a few commits back.

I found this as a result of trying to run a migration script that called on /opt/myapp/bin/myapp_rc_exec.sh

I have found this issue only after this commit #670 https://github.com/bitwalker/distillery/commit/4ebfe9a6464d981b77008e083d258b4b720c6838#diff-bb0b28dac91fa3fff22ffea720be6334

Any advice as to the difference between the two versions of start_erl.data and what is the reasoning behind the code below is would be greatly appreciated.

RELEASE_MUTABLE_DIR="${RELEASE_MUTABLE_DIR:-"${RELEASE_ROOT_DIR}/var"}"
if [ ! -f "${START_ERL_DATA}" ]; then
    mkdir -p $RELEASE_MUTABLE_DIR
    cp "${RELEASES_DIR}/start_erl.data" "${START_ERL_DATA}"
fi

[joshchernoff]

I believe that I understand how I end up with a discrepancy between the two files because a prior deployment had not cleaned up the start_erl and thus the if condition never failed. Simply cleaning up the prior start_erl file would have fixed this issue for me. Even still I don't understand the need for looking in the mutable directory first.

[rhruiz]

The mentioned change seems to have broken REALEASE_READ_ONLY too. It writes start_erl.data to $RELEASE_MUTABLE_DIR even when read only is set.

[romaluca]

I have the same issue

[sumerman]

Same here

[ohmycto]

Same issue

[zazaian]

Also a problem for me. I've commented on a related issue in the edeliver repository but I suspect this issue lies with Distillery.

[4xposed]

same here

[atonse]

Any plans to cut a new release of distillery to fix this? I couldn't figure out why our deployments were broken since upgrading, and have had to rewrite my deployment scripts to just wipe out the whole target folder and deploy a new release from scratch. If this fixes it, hopefully we can go back to not having to nuke the whole directory.