Trellis: Can we work on a better way of keeping a full trellis build under git?

[partounian]

Submit a feature request or bug report

• [x] I've read the guidelines for Contributing to Roots Projects
• [x] This is a feature request
• [ ] This is a bug report
• [ ] This request isn't a duplicate of an existing issue
• [x] I've read the docs and followed them (if applicable)
• [ ] This is not a personal support request that should be posted on the Roots Discourse forums

Replace any X with your information.

---

Of course there is the roots discourse thread from December, but it has issues in different ways, either overwrites local changes or creates merge conflicts for every single change. I imagine other people have issues also, I think we should come up with a solution to his issue with the subtrees.

[partounian]

@TangRufus You have been doing some great work recently, any ideas? Or how did you setup your project(s)?

[TangRufus]

> How did you setup your projects?

More less the same as the subtrees method, but:

• trellis and bedrock are 2 different git repos
• keep .git despite the doc tells you to delete it
• i also have a branch (tangrufus/trellis@project-template) to keep all my common customization to start a project
• 3 git remotes for every project:
  
  
  
  • roots/trellis
  
  
  • tangrufus/trellis
  
  
  • actual origin of the project
  
  

$ git clone -o roots https://github.com/roots/trellis.git www-example-com-trellis
$ cd www-example-com-trellis
$ git remote add tangrufus https://github.com/tangrufus/trellis.git
$ hub create -p
$ git remote -v
origin  https://github.com/TangRufus/www-example-com-trellis.git (fetch)
origin  https://github.com/TangRufus/www-example-com-trellis.git (push)
roots   https://github.com/roots/trellis.git (fetch)
roots   https://github.com/roots/trellis.git (push)
tangrufus   https://github.com/tangrufus/trellis.git (fetch)
tangrufus   https://github.com/tangrufus/trellis.git (push)

## Merge my project temaplate
$ git fetch --all
$ git merge tangrufus/project-template

## Do your job...
## Commit and push to `origin` as usual

## When roots/trellis has been updated...
## Important: Reading change logs, commit messages and `git diff` are necessary
## Tips: Make use of git branches
$ git fetch --all
$ git merge roots/master

Do I recommend everyone to use this method?

No. Use it only if you are comfortable with git. Otherwise, git gives you more headache than benefits.

Should you always keep your forks update with roots/trellis?

Yes! Always!
This is actually missing from the doc: the doc tells you to delete .git but gives no instructions about updating.

However, updating Trellis is challenging, I don't think of a good and easy way that suitable for everyone.

Edit: By forks, I mean both origin and tangrufus remotes in the above example.

Avoiding merge conflicts

Since I use git a bit differently than the subtrees method, I got less merge conflicts.

Tips:

• Whenever possible, don't change existing files in roles/*
• When changing j2 templates, make use of variables
• When changing variable values, define them in group_vars/<env>/xxx.yml
• When a j2 template doesn't allow customizing with variables, submit pull requests, example: #856
• When you need to add more tasks:
  
  
  
  • Bad: change existing files in roles/*
  
  
  • Good: make a new role and add it into dev.yml / server.yml
  
  
  • Best: extract it to galaxy.ansible.com
  
  
  • see also: #830, #882
  
  
• Whenever possible, don't use Nginx child templates because you lose all the benefits Trellis update gives you

Let say you want to change something in sites-available/example.com.conf:

• Best: define variables in group_vars/<env>/xxx.yml
• Good: template out to {{ nginx_path }}/includes.d/{{ item.key }}/xxx.conf but beware Trellis might delete your files during this task, see how I do it
• Bad: use Nginx child templates is the last resort

⚠️

• Reading change logs, commit messages and git diff are necessary
• No merge conflict doesn't mean it won't break
• Same commit doesn't mean same server, see: https://github.com/roots/trellis/pull/881#issuecomment-328186152

The ultimate way to avoid merge conflict

Get it merged into roots/trellis

[partounian]

And just to confirm you create a second repo just for bedrock and the
actual WP related stuff?

[TangRufus]

Correct.

For every project, I have 2 git repo:

• example-project-com-trellis
• example-project-com-bedrock

You need to change group_vars/<env>/wordpress_sites.yml accordingly

https://github.com/roots/trellis/blob/db89d49a18e60b5c9e1e8a1a4901080bfe871e26/group_vars/production/wordpress_sites.yml#L12-L13

[swalkinshaw]

Of course there is the roots discourse thread from December, but it has issues in different ways, either overwrites local changes or creates merge conflicts for every single change

If you make changes to Trellis as @TangRufus outlined, merge conflicts and overwritten local changes shouldn't happen too much.

One thing which I don't know has been mentioned on on Discourse is specifying merge strategies for specific sub paths.

So if you know that roles/ is free of local changes, you can run git merge -X theirs subtree=trellis/roles --squash trellis/master (or something like that).

-X theirs means git will automatically pick every change from trellis/master without prompting for conflicts. ours does the reverse which can be useful for certain files/dirs.

[swalkinshaw]

We definitely need some guides/docs about:

• how to properly customize/change Trellis
• how to update Trellis

[partounian]

I believe it is -X ours not yours, I'll definitely follow Tang's plan
in the future, it'd probably be a headache for my pre-existing ones.

[swalkinshaw]

Correct, updated it

[partounian]

@TangRufus Hey Tang, I've almost wrapped up a setup according to your specs, except I'm stuck on a nginx-includes situation. Basically I want to add location blocks to remote servers, in my case one file to do browser caching and another to disable logging for the favicon.

I feel like browser caching should be added into Trellis and enabled when we enable cache. Thoughts? @swalkinshaw

[swalkinshaw]

We can't really do that automatically. Just because you enable fast-cgi caching doesn't mean you have a proper setup with asset digests.

[partounian]

Super sorry @swalkinshaw I was just reading other the tickets about browser caching, forgot that you have some concerns with browser caching.

[strarsis]

Couldn't we make a "child config" from the base roots config?
It works so well with themes 😄

[partounian]

@TangRufus I've been using your method for a current project and it works great. Two notes though.

It can be slightly simplified by your project's trellis having two remotes not three, one being origin and the second being your user's trellis. You would just keep project-template up-to-date and rebase off of that instead of roots remote.

And the second one is a question. Any idea how to keep bedrock up-to-date without having to deal with merge conflicts for composer.lock?

[TangRufus]

deal with merge conflicts for composer.lock?

You don't. First resolve conflicts in composer.json, then $ composer update. Let composer generates a new composer.lock for you.

[partounian]

Yup that's what I do. I know it's best practice to keep composer.lock in
vc, but I wonder if it'll work fine without it being in vc. Especially
since it's wp packages and not anything with other Composer dependencies.

On Sun, Dec 3, 2017, 7:01 PM Tang Rufus [e-mail] wrote:

deal with merge conflicts for composer.lock?

You don't. First resolve conflicts in composer.json, then $ composer
update. Let composer generate a new composer.lock for you.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/roots/trellis/issues/883#issuecomment-348848791, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACbIG0vR9isVNOYp62U5IAn_8HuayeBmks5s82CMgaJpZM4PSJjF
.

>

Thank you,
Patrick Artounian

[TangRufus]

It works without composer.lock. However, the deployment will be a little bit different. Trellis may _silently_ upgrade your wp core / plugins / themes during deploy.

Reason

Trellis runs $ composer install during deploy.
$ composer install with .lock always install the exact versions listed.
$ composer install without .lock works as $ composer update.

Workaround

If you really want to exclude .lock from git, always specify the exact package versions in composer.json. Otherwise, trellis will _silently_ upgrade your wp core / plugins / themes during deploy.

Recommendation

Commiting your composer.lock is the best practice.
Use the workaround only if you have a very strong reason.

See:

• https://github.com/roots/trellis/blob/master/roles/deploy/hooks/build-after.yml
• https://getcomposer.org/doc/01-basic-usage.md#installing-without-composer-lock
• https://getcomposer.org/doc/articles/versions.md#exact-version-constraint

[partounian]

Yup, that is what I thought. I actually always specify the exact version, as not all minor versions can be without breaking changes.

[robrecord]

deal with merge conflicts for composer.lock?

You don't. First resolve conflicts in composer.json, then $ composer update. Let composer generates a new composer.lock for you.

To avoid unintentionally upgrading packages, use composer update --lock instead. This will only update the lock file.