You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docs offer a way to use Git Automation with Laravel Scheduler to consolidate changes. Unfortunately the php artisan command php artisan statamic:git:commit does not work via the Laravel Scheduler or Cronjob but it works when executing it manually via terminal.
I've set up two scheduler tasks in console.php: one for committing, one for pushing.
The log file shows the success message saying "Content committed", but a git status proves that nothing has been committed. When executing php artisan statamic:git:commit manually in the terminal, it commits correctly and the second scheduled task of pushing also works.
To test it without the usage of schedulers, I've set up the two tasks as cronjobs:
The behaviour was the same: first one only returned a success message without actual commit, but after manual committing the push was successful.
When nothing is to be committed, the log message also says so accordingly. So it seems like the command is indeed executed, and also kinda works but not really.
I also don't think it's a git issue, since the commit and push work per se.
How to reproduce
Set up Git Automation. Use these settings in the .env:
Set up the two scheduler tasks as shown above or the two cronjobs. Make a change in a tracked file. Track if the commit command was successful with git status.
Our host provider has several php functions disabled for security reason, for example exec(), shell_exec(), system(), dl() and passthru(). I've enabled them for testing purposes, but that didn't change anything. There might be possibly some other similar setting responsible, although I doubt it personally.
The text was updated successfully, but these errors were encountered:
Can you try running git status as a cron job and post the output?
Also, I'm assuming your cron jobs are running as the same user as you're logged into when executing the commands manually? If they're not, that might be causing issues.
# On branch main
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: content/collections/pages/2025-01-06.test.md
#
no changes added to commit (use "git add" and/or "git commit -a")
Yep, running whoami via cronjob is the same user as the one I log in with to execute the command.
Bug description
The docs offer a way to use Git Automation with Laravel Scheduler to consolidate changes. Unfortunately the php artisan command
php artisan statamic:git:commit
does not work via the Laravel Scheduler or Cronjob but it works when executing it manually via terminal.I've set up two scheduler tasks in
console.php
: one for committing, one for pushing.The log file shows the success message saying "Content committed", but a
git status
proves that nothing has been committed. When executingphp artisan statamic:git:commit
manually in the terminal, it commits correctly and the second scheduled task of pushing also works.To test it without the usage of schedulers, I've set up the two tasks as cronjobs:
The behaviour was the same: first one only returned a success message without actual commit, but after manual committing the push was successful.
When nothing is to be committed, the log message also says so accordingly. So it seems like the command is indeed executed, and also kinda works but not really.
I also don't think it's a git issue, since the commit and push work per se.
How to reproduce
Set up Git Automation. Use these settings in the
.env
:Set up the two scheduler tasks as shown above or the two cronjobs. Make a change in a tracked file. Track if the commit command was successful with
git status
.Logs
No response
Environment
Installation
Fresh statamic/statamic site via CLI
Additional details
Our host provider has several php functions disabled for security reason, for example exec(), shell_exec(), system(), dl() and passthru(). I've enabled them for testing purposes, but that didn't change anything. There might be possibly some other similar setting responsible, although I doubt it personally.
The text was updated successfully, but these errors were encountered: