Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we work on a better way of keeping a full trellis build under git? #883

Closed
partounian opened this issue Sep 9, 2017 · 18 comments

Comments

Projects
None yet
5 participants
@partounian
Copy link
Contributor

commented Sep 9, 2017

Submit a feature request or bug report

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 partounian changed the title Can we work on a better way of keeping a full trellis build under git Can we work on a better way of keeping a full trellis build under git? Sep 10, 2017

@partounian

This comment has been minimized.

Copy link
Contributor Author

commented Sep 10, 2017

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

@TangRufus

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2017

> 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: #881 (comment)

The ultimate way to avoid merge conflict

Get it merged into roots/trellis

@partounian

This comment has been minimized.

Copy link
Contributor Author

commented Sep 13, 2017

@TangRufus

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2017

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

repo: git@github.com:example/example.com.git # replace with your Git repo URL
repo_subtree_path: site # relative path to your Bedrock/WP directory in your repo

@swalkinshaw

This comment has been minimized.

Copy link
Member

commented Sep 18, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 18, 2017

We definitely need some guides/docs about:

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 18, 2017

@swalkinshaw

This comment has been minimized.

Copy link
Member

commented Sep 18, 2017

Correct, updated it

@partounian

This comment has been minimized.

Copy link
Contributor Author

commented Oct 22, 2017

@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

This comment has been minimized.

Copy link
Member

commented Oct 22, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 22, 2017

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

@strarsis

This comment has been minimized.

Copy link
Contributor

commented Nov 26, 2017

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

@partounian

This comment has been minimized.

Copy link
Contributor Author

commented Dec 1, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Dec 4, 2017

@TangRufus

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2017

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:

@partounian

This comment has been minimized.

Copy link
Contributor Author

commented Dec 9, 2017

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

@robrecord

This comment has been minimized.

Copy link

commented Apr 10, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.