-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Crontab rewrite with sections causes migration errors #3768
Comments
Hello @SimJoSt I'm sorry to hear your experience, I of course agree 100% that it should not be a breaking change in a not-major release. |
@SimJoSt I noticed your other issue (#3769) as well, I have the feeling there is something strange going on with the yaml config translation, I must admit that I have not used or seen that style of configuration before. Especially since you mention the default setting for the identifier. There is a default value set as can be seen here: https://github.com/deployphp/deployer/blob/master/contrib/crontab.php#L33-L35. For reference, I use the following code: $receivers = implode(" ", [
'scheduler_main_schedule',
]);
add('crontab:jobs', [
"30 1 * * * {{bin/php}} {{current_path}}/bin/console messenger:consume $receivers --time-limit=86400 >> /dev/null 2>&1",
]); I've never even set the identifier and it works without issues. I might have time to investigate this more but I'm not sure when. |
We've been using the
crontab
recipe in our config for some time now, and I welcome the rewrite with sections, as it prevents duplicate entries when the crontab config is changed and resynced.Without initially knowing about the change, it broke some of our applications and no crontab was running for some time. Only the terminal output messages, pointed me towards the new behaviour. I get, that this is only a change in a smaller recipe, but it seems to be a breaking change.
If there is a migration in place, it shouldn't be an issue. However, I noted some issues while using it and migrating existing applications to it.
Running the
crontab:sync
task showed it recognized a previous job in the crontab config on the server, said it would move it to the section, said it couldn't find the section, and said it would create the section.The section was created, and the previous job was removed. However, the pre-existing job was not created anew in the new section. It seems like it cannot perform the migration and creation of a new section at the same time, breaking existing configurations.
The fix is to run the
crontab:sync
task again, which fixes the problem.Before:
Migration:
Re-run:
The text was updated successfully, but these errors were encountered: