finnlesueurgmailcom - 3 weeks ago

Hey all,

I’d like to get some opinions on how to effectively use git for a multi-site PyroCMS installation!

I would like to achieve tracking of composer.json/composer.lock so I can do composer update locally and just do composer install on my VPS.

I would also like to achieve tracking of the root .env file as well as the resources/{siteslug}/.env file so I can manage geocoder api keys, database credentials, and all that jazz.

I’m honestly not sure what else I should track, or if should I just gitignore everything except the composer files and the .env files? Any advice on best practice would be appreciated!

Answer

frednwt - 3 weeks ago

Tracking he composer.lock is perfectly normal for a project. The recommandation to not track it is only for libraries.

But tracking the .env, is not the best thing to do. It may compromise passwords / secret keys. Also, you have a risk that someone change it localy and commit it (which will break the prod). Better just improve the .env.example if needed.

So I agree with edster, keep the standard .gitignore of Pyro. :)

edster - 3 weeks ago

Keep the standard git ignore with pyro and commit the .env and lock. You might want to keep some storage models unless you are going to compile them on push

finnlesueurgmailcom - 3 weeks ago

Maybe this wouldn’t be an issue with external file storage, but surely I don’t want to be committing files I’ve uploaded to storage/ locally to my repo?

Also what about /addons? If it’s all in composer.lock then I could ignore that.

edster - 3 weeks ago

Those get stored in the public directory, by default most of that directory is exluded by the default git config.

stuff in /addons you are going to want to commit because anything in there isn't in the composer file (if it is you are double pulling and may have version mismatches and other issues)

frednwt - 3 weeks ago

Tracking he composer.lock is perfectly normal for a project. The recommandation to not track it is only for libraries.

But tracking the .env, is not the best thing to do. It may compromise passwords / secret keys. Also, you have a risk that someone change it localy and commit it (which will break the prod). Better just improve the .env.example if needed.

So I agree with edster, keep the standard .gitignore of Pyro. :)

ryanthompson - 2 weeks ago

I would not commit the .env cause by nature it's supposed to be environment specific. I've seen arguments for and against the composer.lock but that depends on your package management style. We use semver versioning so I tend to run composer update --no-dev -o on servers rather than composer install. Cause I know the updating will be limited to patches by default.

ryanthompson - 2 weeks ago

I do however usually duplicate and commit my .env as a .env.example file. So I can easily copy and modify for remotes / new environments.

finnlesueurgmailcom - 2 weeks ago

Thanks everyone!

For now I have settled on an extended version of the default .gitignore to get rid of some stuff that I really don’t see the need for (but maybe I could just delete a few of them?).

.env
.coverage
/bin
/core
/build
/vendor
/coverage
/node_modules
/bower_components

# Added by Finn
/addons
/resources
/docs
/logs
log.log
error.log
/public/.htaccess

Decided to go with not commiting the .env files although I still think I might do something similar to @ryanthompson so I can easily manage the env variables from my dev environment. I’m the only one with access to my core repo and I don’t think that’ll ever change so I’m not worried about that so much.

The only thing I have run into is that I develop my addons in the addons/ folder, but when I do a composer update on my dev machine so I can commit my composer.lock file, I then get a copy of each module in core/finnito/ and then get a bunch of ambiguous class resolution warnings! I might have a post composer update script for my dev environment that removes all folders from core/finnito/ because that would seem to fix it. Any thoughts?

ryanthompson - 2 weeks ago

Sounds like you are putting your addons into your composer file? Do one or the other:

  • Develop and keep your addons in the addons directory and out of your composer.json file.
  • OR (what I typically do if they'll ever BE in the composer.json file) add them to composer.json and --prefer-source when you bring them in so it clones them and you can continue working on them. Using requires like 1.0.x-dev or master-dev depending on your branch (1.0 or master).

finnlesueurgmailcom - 2 weeks ago

Hah yeah you are right - they will all go into my composer.json at some point because they’re all headed for my server so I’ll develop in core/finnito/ and use the —prefer-source flag. I didn’t know about that flag before, so thanks! That’ll help a heap!

finnlesueurgmailcom - 2 weeks ago

Yo @ryanthompson - could you give an example of how you setup your local source for a repo? I'm having a little trouble setting it up!

The repo can't be located in core/finnito/whatever, so do I have to put it elsewhere and put its location in my composer.json and then run composer update --prefer-source whenever I want to bring my changed into my dev environment?

ryanthompson - 1 week ago

If it's a 1-off addon for a job it goes straight into addons/* and stays there for the project. No composer versioning for it.

However if I am working on a new addon that will be redistributed - as soon as it's v0.1 worthy I commit it from addons/ to it's own repo. Delete the addon. Then add the require in composer.json and update with --prefer-source so I can continue working on it in core/