Store settings about gitify HOT 7 OPEN

Maybe this can tie in to some very-abstract-which-I-have-not-yet-thought-through-idea on supporting environments. Maybe you would have this in your .gitify to version specific settings:

name: foo
data_directory: _data
data: 
  content:
    type: content
    etc: etc
  settings:
    type: settings
    keys: [site_name, some_setting]
environments:
  live:
    setting_key: setting value
    other_setting_key: setting value
  dev:
     setting_key: dev setting value 

from gitify.

Ooh, I like that idea. Would the keys under data->settings be repeated under the environments, or would it be more like "any key defined in any of those locations would be saved"?

Would it make sense to make a UI within MODX to be able to edit the .gitify file? Particularly with settings, it would probably make sense to be able to do them with a series of checkboxes. Also, given the number of settings, would it make more sense to explicitly exclude specific keys rather than explicitly include keys?

from gitify.

Ooh, I like that idea. Would the keys under data->settings be repeated under the environments, or would it be more like "any key defined in any of those locations would be saved"?

I'm thinking they're two different things. The data>settings is for settings that you want to have the same value no matter the environment, while the environments covers settings that are specific to the environment... something like contentblocks.debug could be enabled on a dev environment, for example, but disabled on stage and live.

The default environment might be set in a system setting, or could be passed on the command line like Gitify build --env=live

Would it make sense to make a UI within MODX to be able to edit the .gitify file? Particularly with settings, it would probably make sense to be able to do them with a series of checkboxes.

Good idea :D A "Gitify Configuration" component that basically writes the .gitify file and perhaps has some git functions would be super cool, and definitely help get non-technical people on board with the workflow.

Also, given the number of settings, would it make more sense to explicitly exclude specific keys rather than explicitly include keys?

Not entirely sure about that.

Maybe additional options (like namespaces: [redactor,contentblocks] and exclude_keys: [contentblocks.debug, foo.bar]) would make it easier to add large amounts of settings if you want them all in, but I think as far as core settings go it would be best to specifically add which ones you want included, as some settings may have unintended side effects?

from gitify.

I'm thinking they're two different things. The data>settings is for settings that you want to have the same value no matter the environment, while the environments covers settings that are specific to the environment... something like contentblocks.debug could be enabled on a dev environment, for example, but disabled on stage and live.

Hmm. I think we're mostly talking about the same thing, but... How are you thinking this would be stored? I think it might make sense to have a settings.yaml file, which would be updated based on what .gitify tells it in terms of what settings should be stored. That is, .gitify says:

  settings:
    type: settings
    environment: shared
        keys: [site_name, some_setting]
    environment: live
        keys: [setting1, setting2]
    environment: dev
        keys: [setting1, setting2, setting3]

while settings.yaml has:

environments:
  shared: 
    site_name: My awesome site
    some_setting: Some value
  live:
    setting1: Monkey
    setting2: Banana
  dev:
    setting1: Horse
    setting2: Apple
    setting3: My setting that isn't stored within gitify on the live site

(this could also be done as settings_shared.yaml, settings_live.yaml, and settings_dev.yaml)

I guess there are two problems I see with doing implicit includes:

1. Unless we're hooking into the install process, every time an extra is added, someone needs to remember to go update .gitify to add any settings it might include (which may be somewhat difficult to even track down) -- and I don't know whether hooking into installation is even possible.
2. I have a site with a not-too-insane number of extras, and there are over 300 settings. That's going to get really cumbersome within the .gitify file, I think.

In the use cases I can think of, it's far more likely that you'd want to have everything except for a few settings, rather than only having a few settings stored. I would say the "sensible defaults" method would be exclude.

Maybe, though, we could do something like:

  settings:
    type: settings
    method: exclude
    environment: shared
        keys: [site_name, some_setting]
    environment: live
        keys: [setting1, setting2]
    environment: dev
        keys: [setting1, setting2, setting3]

Alternatively, we could set the method at the environment level:

  settings:
    type: settings
    environment: shared
        keys: [site_name, some_setting]
        method: exclude
    environment: live
        keys: [setting1, setting2]
        method: exclude
    environment: dev
        keys: [setting1, setting2, setting3]
        method: include

I think that might get slightly confusing, but it's something to think about.

from gitify.

Environments are already in?
Is this documented somewhere?

from gitify.

Environments are only implemented in GitifyWatch currently: https://github.com/modmore/GitifyWatch#4-configure-the-gitify-environments

from gitify.

Ok, thanks for the clarification 👍

from gitify.