deploy fails (correctly); weird state of deployer related files on our server

[m1rm]

Hello :)

I wanted to deploy a project and deployer failed correctly because the release already existed.
The current release is 57, the release deployer tried to create was 58, which already was present in the releases folder.

So I checked on the server and I found:

• a .dep/releases file which seems to contain timestamps and version numbers, separated by comma

  • exemplary content of one line: 20180808141921,1
  • the file goes up to number 92 with a timestamp from last year

• a .dep/releases_log file, that contains more detailed info

  • exemplary info of one line:{"created_at":"2024-10-07T14:08:24+0000","release_name":"1","user":"xxx","target":"main"}
  • the file is at release 57

I am wondering: did the files deployer uses to track the current release change between deployer 6 and 7.3.0? I am wondering this bc. the file with higher numbers (and also the higher number releases) are from times where the project was on deployer 6 and then I updated to 7.3.0

Further Info:

• I am using the recipe/symfony.php recipe
• php-version: 7.4
• composer-version: v2
• deployer-version: 7.3.0

Thanks in advance :)

[antonmedv]

Yep—Deployer changed release tracking in v7.

• v6: used .dep/releases (timestamp,number).
• v7 (7.3.0): uses .dep/latest_release + .dep/releases_log.

Your v7 thinks latest is 57, but releases/58 already exists from v6 → collision.

Fix (pick one):

• One-off: dep deploy -o release_name=<NEXT_FREE> (e.g., highest dir is 92 → use 93).

• Persistent:

  HIGHEST=$(ls -1 {{deploy_path}}/releases | sort -n | tail -1)
  echo "$HIGHEST" > {{deploy_path}}/.dep/latest_release

  Next deploy creates HIGHEST+1.

(You can ignore or remove .dep/releases; v7 doesn’t use it.)