backdrop-contrib / backdrop-drush-extension

A set of commands and boot class for Drush and Backdrop CMS.
GNU General Public License v2.0
13 stars 18 forks source link

Config Versioning removed on BCEX with Lando #228

Closed halofx closed 4 years ago

halofx commented 4 years ago

When executing lando drush bcex, the .git repo is deleted with all the old config on export.

It has been 3-4 months since I had to do a config export on a Backdrop site, so I don't know which Drush version or extension version Lando was using at the time.

I am using the Versioned Staging method for config management, the Drush and extension versions provided by Lando default. Lando 3.0.6 Drush 8.3.2 Backdrop Drush Ext 1.x-1.x (according to lando drush version)

serundeputy commented 4 years ago

@halofx thanks for reporting.

Are you just versioning the staging directory or separately versioning the staging directory?

If that is the case it makes sense that the .git directory is deleted (usually folks do not have a .git in there staging directory.

drush bcex needs to respect configuration additions and deletions and the way it does that is to remove the current staging directory and replace it with an export of the current active directory.

The pattern I always use and I've seen used most frequently with the Versioned Staging method is manage the entire PROJECT_ROOT and/or BACKDROP_ROOT with version control like this:

PROJECT_ROOT
  - .git
  - config
  - BACKDROP_ROOT
    - index.php
    - core

and then your .gitignore looks something like this:

node_modules
vendor
config/active
.env
*.sql
*.gz
*.sql.gz
htb-outline.md
config/staging/devel.*
tst.php

If it is the case that you are just using git for the staging directory that code could be written for drush that will figure out if a .git directory is present and behave differently in that case, but I'd recommend you version control your entire Backdrop code base instead.

halofx commented 4 years ago

Thank you for the reply. Yes, I have a .git in config/staging , and in BACKDROP_ROOT, and had been tracking the two separately. So working off the presumption that BCEX now deletes the whole staging directory, then I do need to rework my versioning strategy. It did seem like previously BCEX didn't wipe out all the files, but just copied them, as I would have issues that needed manual attention when I would remove modules, or other config.

I had been working off the documentation here: https://api.backdropcms.org/documentation/versioned-staging-directory Which focused on tracking staging, but no mention of ignoring active. So this is probably why I tracked staging by its self, and it did work for some time.

serundeputy commented 4 years ago

@halofx here is how i do it: https://howtobackdrop.com/posts/backdrop-cms-project-starter

halofx commented 4 years ago

Thank you! These kind of examples are very helpful.