bitwalker/distillery

Discrepancies between two versions of the start_erl.data

joshchernoff opened this issue · 8 comments

joshchernoff commented

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
4ebfe9a#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 commented

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 commented

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 commented

I have the same issue

sumerman commented

Same here

ohmycto commented

Same issue

  • 👍1
zazaian commented

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 commented

same here

atonse commented

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.

  • 👍14