Disabling git-sync when developing

Hello,
I have Grav running remotely in a Docker container, syncing regularly with my git repo. Next I’d like to disable git-sync in development mode so my local instance doesn’t add/commit posts and changes I’m not ready to send to production yet. How do I do this?
I looked into environments, but I’m guessing that since git-sync runs via the scheduler, it uses the localhost environment. So I’m assuming I can’t disable the git-sync plugin in the localhost environment without disabling it everywhere–or, at least, without disabling the bit that runs in the scheduler, which would defeat the purpose.
Am I misunderstanding, or is there some other way to do this?
Thanks.

@nolan, Never worked with Git-Sync, but wouldn’t it work if you disable the plugin on localhost and manually push changes to Github?

I guess that after pushing, a Github webhook will then trigger your production server and the server will in turn fetch the changes from Github.

As said, just a guess…

I don’t think that will work. I can disable the scheduler completely and just use webhooks, but then the site will only pull changes from Git. I want it to push them there as well, including new accounts and other changes that don’t appear in the plugin configuration.
Is there any way to have the scheduler use a different environment? If I can somehow get production using a different environment in the scheduler, then I can just leave it disabled on localhost.

@nolan, Running help shows there is an --env parameter. So, it seems you should be able to start Grav using a different environment.

$ bin/grav scheduler --help
Description:
  Run the Grav Scheduler.  Best when integrated with system cron

Usage:
  scheduler [options]

Options:
  -i, --install         Show Install Command
  -j, --jobs            Show Jobs Summary
  -d, --details         Show Job Details
  -r, --run[=RUN]       Force run all jobs or a specific job if you specify a specific Job ID [default: false]
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
      --env[=ENV]       Use environment configuration (defaults to localhost)
      --lang[=LANG]     Language to be used (defaults to en)
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  Running without any options will force the Scheduler to run through it's jobs and process them

Hmm, I might be able to force a different environment in my development vs. production container. I’ll need to poke that a bit.
But I do have env/localhost/config/plugins/git-sync.yaml with enabled: false and my production environment appears to still be syncing with git. Does disabling the plugin not disable its schedule additions? If that isn’t the case, then I may be on the wrong track for conditionally disabling this.

@nolan, Hum, I’m not sure what the impact is of --dev on other configs.

Alternatively, the Scheduler uses config file config/plugins/scheduler.yaml to load custom jobs. See code line 75

$saved_jobs = (array) Grav::instance()['config']->get('scheduler.custom_jobs', []);

If that honors the --env setting, you might clear the value for custom_jobs in user/env/localhost/config/scheduler.yaml.

I’m not familiar with git-sync and Scheduler, so I’m not sure if git-sync is listed in schedular.custom_jobs.

I just filed Disabling plugin should disable schedule additions · Issue #210 · trilbymedia/grav-plugin-git-sync · GitHub. Essentially, it looks like enabled is a setting in the plugin blueprint, but either it isn’t honored or it’s enforced at some level other than the git-sync plugin itself. I don’t see where it is referenced in git-sync.php, and it definitely doesn’t appear to influence whether the plugin adds its jobs to the scheduler.

Not sure how to continue. Grav is aggressively updating my local git repo, including committing changes and posts that are incomplete and not ready to go live. I’m fairly happy with how this works remotely, including pulling in configuration/plugin changes from my git remote into the production environment. But aside from automated changes made in the admin panel, I need it to leave my local repo alone and not add changes that aren’t finished. As of now I’m afraid to tweak anything unless I can finish it before the scheduler runs its next iteration.

Thanks for all your help so far.

@nolan, Please ping back any interesting info you get on Github.

Cool, so as per discussion on the above issue, it seems like the CLI runs in a cli environment, which explains why disabling the plugin in the localhost environment as per the debugger docs didn’t work. So now I just need to pass a different environment to the scheduler when developing locally.
I’m going to play with Docker build-args and see what I can come up with, but it should be possible to disable things locally. I’ll report back with what I manage.

I think you’re on the right track. Here is my hot take, I think we should summon @djamil who wrote the plugin to see if he can clarify.

When the plugin was enabled (or installed), it set up a syncing job in Grav’s scheduler. Since that runs independent of any plugin, I suspect that when you disable the plugin in your environment, that job is not disabled. If I’m right, I think it ideally should be if possible, and an issue could be raised.

To work around and confirm my suspicions, look in user/config/scheduler.yaml and find the job under status:. You could set it to disabled here, or do so in env/localhost/config/scheduler.yaml. If that doesn’t work, the nuclear option is to disable the scheduler in your container’s crontab.

Note about identifying the host name as ‘localhost’: if you are doing the same on your other environments using docker (or even not), they will also identify as localhost and honour those environment configs. Depends on your setup, just beware.