Consolidate publish settings in config.yml

[diwakergupta]

There's really no reason why the publication settings need to be a in a separate publish.yml or publish.json. Having all config in one location eliminates confusion and reduces friction for new users.

[plusjade]

My thought process was that you might expose sensitive information in a publish.json file like keys, or ip addresses? etc. It's more of a convention to keep deploy scripts out of version control. I know users shouldn't need to hard-code sensitive information in a command-line expression, but that doesn't mean they won't.

I assumed to put it in the config.yml file but then it would need to be version controlled in order the repo to work.

Thoughts?

[diwakergupta]

That's a fair point, though I would still suggest including all config in config.yml and allow users to override certain settings if needed via a separate file. Other build systems do something similar (e.g. maven with pom.xml and settings.xml/settings-security.xml and gradle with build.gradle and gradle.properties). Feel free to close this out.

[plusjade]

I like your suggestion. As you said it's less confusing for users getting started. The "sensitive data" use-case would be further along in the user's journey so better to make the start of the journey easy as possible. I'll add this to ruhoh 3.0 for sure and depending on when I estimate 3.0 release to be, I'll consider upgrading 2.6 as well. Thanks for your input on this!

[indolent-gnathostome]

I like both ideas. Perhaps the default project should include a config.yml where the relevant section is commented out, accompanied by a notice explaining the security risks and how to use publish.yml. Also, if a user embeds sensitive information in config.yml, it might be best to remind them of the risks (and the safer alternative) when they compile.

[waynedpj]

just to add in a different use case/view point, i personally prefer the separate configuration files. not only for keeping sensitive data private, but also for keeping concerns separated (e.g. config.yaml for setting up Ruhoh, site.yaml for generic site metadata, publish.yaml for publication info). in fact, i often find my self wanting a YAML include directive for building the data context from multiple files. this splitting up of data allows projects that are designed a certain way to be more easily reused (e.g. take the config.yaml and publish.yaml, change the site metadata and viola, a new site skeleton based on the old one).

so while i agree that the basic/starter use case should allow the data to all be put into the same data file, it should not prevent users from keeping things separate.

in fact this is something i would like to see in Ruhoh in general: allowing data files to be defined anywhere and be merged in the "cascade" similar to how layouts and partials work. thus, a page that references some data media.path would first use any local data files in the same directory/collection, then if that was not available, go up to the parent collection (i am obviously assuming there is sub collection support .. another request ;P ), if not available, up again until root where the theme would be checked for data and then finally the top level config context is checked. i think Ruhoh does something similar but currently properties are overwritten, instead of masked by more specific/local values.

i apologize for jumping on this thread, just wanted to give another POV. and i will make a feature request with the above brain dump.

peace, w

[indolent-gnathostome]

in fact this is something i would like to see in Ruhoh in general: allowing data files to be defined anywhere and be merged in the "cascade" similar to how layouts and partials work.

This is an excellent suggestion. When I first saw the cascade, I assumed it applied to everything. It's such a powerfully simple concept, it feels like it should. Discovering what does and does not in fact cascade (and how to work around what doesn't but seems like it should) was a big part of the learning curve early on.

Edit: Holy cow, I just noticed ruhoh/silly.

[waynedpj]

When I first saw the cascade, I assumed it applied to everything. It's such a powerfully simple concept, it feels like it should.

ditto

Discovering what does and does not in fact cascade (and how to work around what doesn't but seems like it should) was a big part of the learning curve early on.

and ditto :+1: