Void rolled back releases

[tangrufus]

Problem A

1. deploy (current symlink to releases/11111111)
2. deploy some changes (current symlink to releases/22222222)
3. find out releases/22222222 is buggy; rollback (current symlink to releases/11111111)
4. deploy bug fixes (current symlink to releases/33333333)
5. find out releases/33333333 is also buggy; rollback (current symlink to releases/22222222)

We already know releases/22222222 is buggy and rolled back in step 3. However, Trellis doesn't know. Trellis rolls back to the last release which older than current

trellis/roles/rollback/tasks/prior-release.yml

Line 21 in ac87cd5

new_release_path: "{{ project_root }}/releases/{{ releases.stdout_lines[(current_release_position.stdout_lines[0] | int - 2)] }}"

Solution A

Write DEPLOY_UNFINISHED to release we move away from.

---

Problem B

If the last release which older than current contains DEPLOY_UNFINISH, rollback fails.

trellis/roles/rollback/tasks/main.yml

Lines 8 to 11 in ac87cd5

	- name: Check whether target release was from a successful deploy
	stat:
	path: "{{ new_release_path }}/DEPLOY_UNFINISHED"
	register: target

Solution B

Clean up old and failed (DEPLOY_UNFINISH) releases at the beginning of rollback.yml

---

Do we count this as beraking changes?

[swalkinshaw]

What if we just deleted roll backed releases? The only downside I can think of is that if you decide to re-deploy a rolled back release it will just take a little longer since it's a full new deploy.

I'm guessing that's rare though since you usually roll back for a reason and apply a fix like you detailed.

[tangrufus]

What if we just deleted roll backed releases?

Do you mean replace https://github.com/roots/trellis/pull/1148/files#diff-1ff8e19172c2564b1d6f0cdc568feebdR28-R31 with something like $ rm -dfr {{ current_release_readlink_result.stdout }} (file module of course)?

The only downside I can think of is that if you decide to re-deploy a rolled back release it will just take a little longer since it's a full new deploy.

Not much differences in deploy speed I believe.
Because shared/source & composer caches are untouched by rollback.yml

[swalkinshaw]

Yep exactly that. I don't know if this changes any of the assumptions in the prior/user release roles though.

[tangrufus]

Note that 0c2dd89 might delete more releases than you expected.

During Clean up old and failed releases, ansible keep_releases: "{{ project.deploy_keep_releases | default(deploy_keep_releases | default(omit)) }}"
Then, at the end of rollback (Remove the old symlinked release), ansible delete 1 more.
Thus, you will have max deploy_keep_releases - 1 releases after rollback.

---

I don't know if this changes any of the assumptions in the prior/user release roles though.

They should work, i.e: look for the newest good (i.e: deploy was successful & never been rolled back) release which older than current

[swalkinshaw]

Seems ok to me. What do you think of the delete method vs the other one?

[tangrufus]

I suggest we keep the rolled back release instead of deleteing it, i.e: revert 0c2dd89

Reasons:

• users might want to look at the source code for debugging
• user might have files generated under the rolled back release, example: https://github.com/ItinerisLtd/trellis-backup-during-deploy
• keeping the rolled back release doesn't hurt and it will be deleted during next successful deploy

Only thing I don't like is hardcoding DEPLOY_UNFINISHED. But I don't find a good solution to keep it in sync with deploy_helper.unfinished_filename (in deploy.yml).

[swalkinshaw]

Sounds good to me 👍

[tangrufus]

Dropped 0c2dd89 & rebased onto master & added changelog

[tangrufus]

rebased, ready for review