Wyklucz konfigurację z importu / eksportu


16

Myślałem, że to prosty przypadek użycia nowego systemu zarządzania konfiguracją, ale nie miałem szczęścia dowiedzieć się, jak rozwiązać ten problem:

Problem

Chcę zapisać konfigurację w git i użyć drush, aby wyeksportować konfigurację podczas programowania, a następnie podczas wdrażania zaimportować konfigurację. Całkiem podobne do przywracania funkcji w Drupal 7. Mój problem polega na tym, że nie chcę przechowywać kodów dostępu w git dla różnych integracji. Powoduje to usunięcie tych konfiguracji
$ drush cim -y

Gdzie spojrzałem

Miałem nadzieję, że będzie prosta lista / konfiguracja konfiguracji, które powinny zostać wykluczone podczas importu / eksportu. Wygląda na to, że w pewnym momencie było, ale musiało zostać ponownie usunięte, ponieważ jest ono obecnie dostępne w wersji Drupal 8.

Przyjrzałem się, w jaki sposób dokonywane są zmiany konfiguracji, porównując aktywny i synchronizowany magazyn, aby zobaczyć, czy istnieje miejsce, w którym mógłbym usunąć zmiany, tak się nie stało. Patrzyłem na to, jak drush importuje konfigurację, ponieważ ma pewne własne wykluczenia konfiguracji, ale nie wyglądało na to, że można ją rozszerzać. Spojrzałem ConfigEvents, ale wydaje się, że wszystko to dzieje się po imporcie, więc nie wygląda na to, że można tego użyć.

Czy czegoś brakuje, czy też nie można po prostu wykluczyć konfiguracji z importu / eksportu?

Odpowiedzi:


7

To nie jest możliwe, aby mieć wyklucza konkretnie, ale jest coś.

Podobnie jak $ conf w Drupal 7, w ustawieniach.php znajduje się $ config, którego można użyć do zastąpienia czegokolwiek w konfiguracji lokalnie. Format to $config['name.of.config']['nested']['key'].

Zauważ, że wszystko, co jest zapisane w konfiguracji, wciąż znajduje się w git, więc albo musisz nie przechowywać żadnych, albo testować kody dostępu w git. Ponadto interfejs użytkownika pokaże, co jest faktycznie zapisane w konfiguracji i obecnie nie dostarczy żadnych wskazówek, że zostało to zastąpione. Istnieją nierozwiązane problemy, które mogą to poprawić.

Rozumiem, że ma to ograniczenia, ale w tej chwili nie można utrzymać czegoś poza eksportowaną konfiguracją. Z tego co wiem.


Zasadniczo więc musisz ustawić / zaktualizować konfigurację w pliku settings.php zamiast korzystać z interfejsu.
googletorp

Tak, to nic nowego. W tym kontekście nic nie zmieniło się w przepływie pracy w d8.

11

Możesz użyć modułu „Config Ignore”: https://www.drupal.org/project/config_ignore

Czy kiedykolwiek doświadczyłeś, że konfiguracja Twojej witryny została zastąpiona przez konfigurację w systemie plików, gdy robisz drush cim?

Nigdy więcej!

Ten moduł jest narzędziem pozwalającym zachować pożądaną konfigurację.


2
config_ignore jest prawdopodobnie najbardziej stabilnym i najprostszym dostępnym obecnie rozwiązaniem, a to rozwiązanie prawdopodobnie najlepiej zaspokaja pragnienie OP, aby mieć „prostą listę / konfigurację dla konfiguracji, które powinny być wykluczone przy imporcie / eksporcie”
bdanin

7

Możesz użyć kombinacji config_ignore i config_split .

Config ignore pozwala zignorować podzbiór jednostek konfiguracji podczas importu (zapobiega także usuwaniu od wersji 2.x). Niestety nie wyklucza to wykluczenia konfiguracji podczas eksportu.

Aby wykluczyć encje konfiguracyjne podczas eksportu, możesz użyć config_split, utworzyć nową encję config_split i pozostawić folder pusty. Zapobiega to eksportowaniu konfiguracji do systemu plików; zamiast tego eksportuje go do bazy danych.

Napisałem Wyklucz konfigurację z zarządzania konfiguracją w Drupal 8 na ten temat.


5

Aby podzielić konfiguracje, możesz użyć https://www.drupal.org/project/config_split .

Wpisz config_split, który udostępnia polecenie konsoli Drupal do importowania i eksportowania filtrowanej konfiguracji. Wkrótce nastąpi integracja Drusha (wszak filtr zainspirowany jest filtrem drski --skip-moduły).

Możesz podzielić eksport na różne katalogi, które możesz następnie zignorować.

Na drupalu w Dublinie 2016 odbyła się bardzo ładna prezentacja osób odpowiedzialnych za inicjatywę CMI, do której zachęcam do zapoznania się bez względu na wszystko.


2

Właśnie przetestowałem @berdir w odpowiedzi nr 1 i działa idealnie. Tylko dodaję małą notatkę: musisz wprowadzić całą konfigurację do tego var, kompletne. Bez tego $ config var nie działa poprawnie.

Coś takiego:

 $config['language.negotiation'] = array(
  'session' => array(
    'parameter' => 'language',
  ),
  'url' => array(
    'source' => 'domain',
    'prefixes' => array(
      'es' => '',
      'pt-br' => '',
    ),
    'domains' => array(
      'es' => 'YourLocalDomain',
      'pt-br' => 'Anotherlocaldomain',
    ),
  ),
  'selected_langcode' => 'site_default',
  'langcode' => 'es',
);

Dokumentacja: https://www.drupal.org/node/1928898

Uwaga z powyższej dokumentacji: „Pamiętaj, że wartości zastąpione przez $ config w ustawieniach. Php nie będą widoczne z interfejsu administracyjnego Drupal”.


3
Nie powinieneś tego robić. Powinien łączyć się ze wszystkimi zdefiniowanymi przez ciebie wartościami, ale może nie działa zgodnie z oczekiwaniami w przypadku niektórych struktur.
Berdir

Och, nie mogłem sprawić, żeby działał poprawnie. Spróbuję ponownie go debugować, a jeśli nie będzie działał poprawnie, może uda mi się otworzyć błąd w d.org. Dzięki!
estoyausente

1
Mogę potwierdzić, że możesz zrobić coś takiego$config['module.settings']['some']['value'] = 'foo';
googletorp

2

Zastanawiam się nieco, dlaczego do tej pory nikt nie wspominał o narzędziach Drush CMI . Magiczne słowa to drush cexyi config-ignore.yml. Będziesz mieć listę, którą możesz dostosować. Potrzebowaliśmy go raz, aby wykluczyć instancje bloku, a jednocześnie przetwarzano bazy bloków.

Chcemy wyeksportować całą konfigurację, ale chcemy wykluczyć pewne wzorce.

Tutaj pojawia się --ignore-listopcja drush cexy.

W naszym projekcie mamy folder ./drush, więc umieszczamy plik w ich nazwie config-ignore.yml z zawartością w następujący sposób.

ignore:
  - field.field.contact_message.*
  - field.storage.contact_message.*
  - contact.form.*
  - core.entity_form_display.contact_message*
  - core.entity_form_display.contact_form*
  - core.entity_view_display.contact_message*
  - core.entity_view_display.contact_form*
  - system.site
  - workbench_email.workbench_email_template.*

Więc teraz my biegamy drush cexyjak tak

drush cexy --destination=/path/to/config-export --ignore-list=/path/to/drush/config-ignore.yml

Tak więc eksportuje aktywną konfigurację, a następnie stosuje listę ignorowania, aby usunąć niechcianą konfigurację.

Teraz po uruchomieniu git statuspowinieneś zobaczyć tylko zmiany, które chcesz zatwierdzić.

Źródło: https://www.previousnext.com.au/blog/introducing-drush-cmi-tools

Instalacja

cd ~/.drush
wget https://raw.githubusercontent.com/previousnext/drush_cmi_tools/8.x-1.x/drush_cmi_tools.drush.inc
drush cc drush

Źródło: https://github.com/previousnext/drush_cmi_tools


1

Korzystanie z konfiguracji split (zalecane)

Moduł konfiguracyjny rozłam powstał specjalnie na tę potrzebę.

Config split jest zintegrowany z drush.

Używanie tylko Drusha

Drush również powinien to zrobić za pomocą --skip-modulesflagi.

Możesz dodać następujące wiersze w pliku drupal / drushrc.php w katalogu głównym projektu, aby zrobić to automatycznie.

$command_specific['config-export']['skip-modules'] = array('devel');
$command_specific['config-import']['skip-modules'] = array('devel');

Zobacz http://www.drush.org/en/master/config-exporting/#ignoring-development-modules

Niestety ta funkcja ma błąd : https://github.com/drush-ops/drush/issues/1820 . Dlatego na razie musisz również dodać te pliki konfiguracyjne do swojego .gitignore, aby wyeksportowane pliki konfiguracyjne nie zostały zatwierdzone. Być może ciągle rezygnują z tej (buggy) funkcjonalności z drush na rzecz config split.


2
Ignorowanie plików konfiguracyjnych w git nie działa dokładnie. Konfiguracja nieeksportowana zostanie usunięta. Na przykład niestandardowe strony paneli zostaną usunięte podczas importowania konfiguracji.
dobrzyns

@ user157272, nawet jeśli importujesz za pomocą drush z ['config-import'] ['skip-modules']?
gagarine

drushrc.php można nawet umieścić poza katalogiem głównym. Na przykład o jeden poziom wyżej, co jest przydatne, gdy pracujesz z Drupalem w konfiguracji kompozytora: github.com/drupal-composer/drupal-project .
leymannx,

To nie działało dla mnie. Dodałem moduły, ale nadal były dodawane do konfiguracji włączania / wyłączania modułów.
Jeremy John

Zaktualizowałem odpowiedź aktualną najlepszą praktyką (split konfiguracji)
gagarine
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.