Crediting author of a patch
1. Clone repo2. By default it should be on dev branch, mostly 8.x-1.x
3. Download a patch locally and apply it by git apply -v filename.patch
4. Delete filename.patch
5. git add .
6. Copy commit message from issue where patch exists. In the bottom of the page there should be Credit and commiting section where full commit message should be available. Like so, git commit -m 'Issue #3117195 by joy29: Filter unnecessary code' --author="rudranil29s
This way you will add a message with an author flag.
7. Push the changes.
8. Create new tag and push it to drupal repo.
9. Create a new release on drupal.org
10. Voilla.
Creating a new release of contrib module (example for svg_icon_field)
Clone module locally, with https://www.drupal.org/project/svg_icon_field/git-instructions instructions AND SET YOUR GIT USER, SO IT'S GOING TO SHOW YOUR COMMIT IN DRUPAL.Like so: git clone --branch 8.x-1.x git@git.drupal.org:project/svg_icon_field.git
Next checkout to branch 8.x-1.x (this branch should be used by default). Next provide your changes on this branch or create a new branch and provide changes there. If the changes are not yours, someone has added a patch you have to download a patch to module's dir, next apply the patch with git apply -v [patchname.patch] and make a commit with relevant message so you credit an author there - like so: git commit -m "Issue #555555 by drupal_username: Description of a change". You can find more info here (Applying a patch section) and here. There's no much of a difference whether you commit your changes to 8.x-1.x branch or new one because right after commit this changes should be pushed to 8.x-1.x - not the branch you created locally. When changes are commited and pushed to 8.x-1.x you need to create a tag with:
git tag 8.x-1.0-alpha6
next git tag to check if it was created, you should be promped with:
8.x-1.0-alpha1
8.x-1.0-alpha2
8.x-1.0-alpha3
8.x-1.0-alpha4
8.x-1.0-alpha5
8.x-1.0-alpha6
next push the tag to origin:
git push origin tag 8.x-1.0-alpha6
new tag is going to mark last commit. Since last commit was the one provided a step before new release is going to contain this change. So all you have to do now is to go to "Add new release" on module page and select a tag you want to release. Select alpha-6 and release it. Now the module should contain the change you've provided. To see the effect on drupal page you have to wait like 5 minutes, then the new version / release of module is going to be presented.
What's the most important is the order. You have to provide, commit and push the changes first and then create a tag and push it. Otherwise it won't work. If tag was created first and commit and push after that you would create the same version of the module because the release will be based on last commit right before tag. So tag is like a mark, so what tag does it saves the last commit hash. Based on it new release is created.
Cross browser testing
linkChange Node version with NVM
It's quite easy, we don't have to tweak $PATH, we can do:nvm ls
This will show us the list of installed node versions with arrow pointing to the currently used one.
nvm use 8.9.4
this will change the version to 8.9.4. To prove that we can type:
node -v
and it says:
v8.9.4
Need a new node version? Easy:
nvm install 10.12.0
Local PHP developemnt / Laravel
To run new instance of Laravel just type:laravel new name_of_your_app
or
go to your dir and type:
laravel new
Laravel comes with this handy CLI tool that allows to create new laravel installations.
To serve your app just type:
php artisan serve
Change public to public_html laravel
https://stackoverflow.com/a/53208776/567058Mac local mariadb service
It's been installed through brew.To start it just type:
mysql.server start
And after that you're able to log in mysql with:
mysql -u root
Laravel comes with node.js oriented front end development
Which means you can use:npm run watch - to watch changes for js and scss
npm run production - which is going to minify your css and js
Convert mov to mp4 with 30fps output file
ffmpeg -i input.avi -r 24 output.aviShow unpushed commits
git log origin/branch..brancheg for site story: git log platform/solas-0000..solas-0000
Unmount Platform.sh and make it work again without restarting Mac
Having vagrant running we type:sudo diskutil unmount force ~/Documents/Platform.sh
vmunmountThen vagrant reload and again we have files mounted in Platform.sh directory.
Mount mydevil with sshfs
cd ~/mydevil_sshsshfs dnawrot@s18.mydevil.net:./domains ./
Stand up Zoom:
IELTS
Database:mysql -u root -p
pwd: root
database: ielts
dump ~/ielts_tiny.sql
describe content_type_ro;
select nid, field_organisation_id_value, field_ro_country_value, field_ro_city_value, field_unique_id_value from content_type_ro limit 20;
select count(nid) from node where type = 'ro';
select * from node where nid = 290731;
select * from content_type_ro limit 10;
Show table sizes in active db:
SELECT table_name ,
round(((data_length + index_length) / 1024 / 1024), 2) as SIZE_MB
FROM information_schema.TABLES
WHERE table_schema = DATABASE() ORDER BY SIZE_MB DESC;
Find longest value. Display length of longest value:
select LENGTH(field_application_type_value) from ro_content_field_application_type order by length(field_application_type_value) DESC LIMIT 1;
select field_application_type_value from ro_content_field_application_type order by length(field_application_type_value) DESC LIMIT 1;
Salesforce
URL: https://test.salesforce.com/user: dawid.nawrot@britishcouncil.pl.developer3
pwd: standard
Campaign ID: 7019E000000IW77QAG
New test data after refreshment:
org id: 00D1w0000000RpD
campaign id: 7011w000000B1TiAAK
Standup
Monday: Gwen
Tuesday: @Simon Yeldon
Wednesday: @Vincenzo Russo
Thursday: @Dawid Nawrot
Friday: @Marcin Grabias
Skroty:
ATs - automated tests
ACs - acceptance criteria
TB - testing branch
LUDZIE:
Marios Ioann - grek
Dakala - Deji
Raj Bhargav Kosara - siniak
Bertan Atalay - gosc z dlugimi wlosami i broda
Naveed - ten sepleniący
Raheem Ali - to ten z orzechami zamiast oczu
vincenzo russo - włoch (zna się na vm)
PROJEKTY:
sklep
solas2 - ogolny projekt z ktorego korzystaja wszystkie wersje jezykowe
wersje jezykowe - z niewielkimi zmianami
white labels
TEST NA PLATFORM.SH:
admin
6603Q~140z3962ia4.9gnf9On
hW41z80mq&gS9Ik%h@c32Hb!l
4H78(d2SvJWX6LFs.ks5U
DEVELOPMENT WORKFLOW:
https://bcdigital.atlassian.net/wiki/display/DEV/Development+Workflow
----
Budowanie testowego srodowiska
----
1. Mozna sprobowac z komendą: platform te -p [site_id] [branch_name] -r
Przykład dla Russia (zqlbujr46j5to) dla branchu solas-5686-vkontakte-test
platform te -p zqlbujr46j5to solas-5686-vkontakte-test -r
Zwykle to przebuduje srodowisko, ale nie bedzie widoczna zmiana z tego branchu dlatego trzeba to trochę inaczej zrobić.
2. Wchodzimy do katalogu sites
3. Robimy deploy strony np. ru, czyli platform deploy -d -A -p zqlbujr46j5to
4. Wchodzimy do katalogu /ru
5. Przechodzimy na branch qa: git checkout qa
6. Ściągamy najnowsze zmiany: git pull
7. Wpisujemy: git co test-5686
Pojawia się komunikat:
Branch test-5686 set up to track remote branch test-5686 from platform.
Switched to a new branch 'test-5686'
I tutaj nie wiem czy przy tym commicie ta branch jest tworzona, czy jak ale z tego co pisze to ta branch chyba juz istniała i jest sledzona zmiana pomiedzy branchem zdalnym, a lokalnym. Prawdopodobnie tak jest, bo to środowisko już wcześniej istniało, utworzyłem je w punkcie pierwszym.
8. Wpisujemy: cat project.make
Wyswietli nam clay plik project.make
9. Wpisujemy: nano project.make
I zmieniamy linię z:
projects[solas2][download][branch] = qa
na taką:
projects[solas2][download][branch] = solas-5686-vkontakte-test
10. Następnie: git add project.make
11. Następnie: git commit -m “Rebuilding env test-5686” (trzeba zmienić te cudzysłowy, bo są inne)
12. Następnie: git push origin test-5686
Tutaj powinna się zacząć przebudowa całego środowiska. Jeśli się skończy można wejść na link podany na końcu lub sprawdzać na bieżąco w platform.sh
13. Teraz środowisko ze zmianami powinno być dostępne do testowania.
Jeżeli potem byly wprowadzone jeszcze jakieś zmiany w PR i chcesz przebudować już istniejące środowisko to nalezy wprowadzic jakas zmianę w pliku CHANGELOG, zwykle jest plik CHANGELOG dla konkretnego branchu i zrobic commit, a nastepnie push i srodowisko jeszcze raz sie przebuduje.
----------------------------------
FIX for creating remote branches
----------------------------------
platform deploy -d -A -p [site_id]
Edutation is Great fix:
Jeśli przy komendzie push pojawia sie blad ze tylko administatorzy moga tworzyc branche na serwerze (remote) i nie da sie wypchnac zmian to nalezy uruchomic komende:
platform branch solas-0000-info qa
Ta komenda pozwoli na uruchomienie nowego buildu na serwerze i jednoczesnie stworzy ten branch. W zasadzie ten build jest nieistotny, bo jeszcze nie sa wypchniete zmiany. W kazdym razie jesli wszystko poszlo ok to powinienem otrzymac taki komunikat:
The environment solas-5663-title-update has been created.
From git.bc.platform.sh:yemse4pemhngo
* branch solas-5663-title-update -> FETCH_HEAD
* [new branch] solas-5663-title-update -> platform/solas-5663-title-update
nastepnie wystarczy zrobic:
git push origin solas-0000-info i zmiany zostana wyslane na server, bo ta sama galaz istnieje juz i lokalnie i na serwerze. Tym samym uruchomi sie tworzenie nowego buildu. Po zbudowaniu dostaniesz linki do nowej wersji buildu z twoimi zmianami.
Inna zmiana:
jesli po git status pojawi sie dodatkowy plik np. yml ktory nie byl zmieniany to dlatego, ze jeszcze nic nie bylo nigdy zmieniane w tej stronie to wystarczy wpisac:
git checkout nazwa_pliku
to powinno go usunac, po kolejnym git status nie powinno go juz wiecej byc.
------
BRAK MOZLIWOSCI STWORZENIA NOWEGO SRODOWISKA TESTOWEGO
------
Jesli nie da sie utworzyc nowego srodowiska testowego to nalezy usunac jedno z istniejacych (tych stworzonych przeze mnie), a jesli sie okaze, ze wszystkie sa nadal w trakcie testow to trzeba sie zglosic do Simona lub Vincenzo, aby stworzyl pusty slot. Mozliwy komuniakat swiadczacy o braku wolnych slotow:
[HttpException]
An API error occurred.
Details:
[url] https://bc.platform.sh/api/projects/dfcocujp5d3mg/environments/qa/branch [status code] 402 [reason phrase] Payment Required [message
] This action would raise the count of environments over its limit. [title] Subscription issue
----
SKLEP NA LOCALU
----
http://shop.local.solas.britishcouncil.digital/en
----
Solas UI - environment
----
https://github.com/bcteam/Solas-UI
----
DRUSH
----
drush @co._local cc all
czyli trzeba dodac kod kraju np. @pl._local
----
KONCZENIE ZMIAN ROZPOCZETYCH PRZEZ INNEGO UZYTKOWNIKA
----
Zalozmy, ze ktos pracowal nad ticketem 5652 i go nie skonczyl. Ale jest branch i chodzi o stworzenie takiego samego branchu lokalnego i polaczenie go ze zdalnym branchem.
1. Budujemy srodowisko
1. bedac na qa: git pull
2. Wpisujemy: git branch -a (to nam wyswietla wszystkie branche i te zdalne i te lokalne wlacznie z tym zdalnym solas-5652)
3. Wpisujemy git checkout -b solas-0000-test
4. Będąc juz przełączonym na ten branch wpisujemy: git pull origin solas-0000-test
5. Dla pewnosci mozna wpisac: git diff qa..solas-0000-test (to nam wyswietli zmiany jakie sa wprowadzone - w tym momencie powinny juz byc widoczne zmiany jakie osoba ktora wczesniej pracowala nad tym ticketem zrobila) - jesli jest cos wiecej niz powinno to:
- wpisujemy: git merge qa
6. kolejny git diff qa..solas-0000-test powinien juz byc bez dodatkowych zmian
7. kontynuujemy prace
----
Przebudowa istniejacego buildu w przypadku kraju
----
Jesli masz juz istniejacy folder z danym krajem i dziala sobie lokalnie, ale wprowadziles jakies zmiany (np. w przypadku solas2, a konkretniej stworzyłeś jakiś nowy moduł, ktory musi byc widoczny w nowym lokalnym buildzie ru), ktore wymagaja przebudowy tego srodowiska to wchodzisz do katalogu np. /sites/ru i wpisujesz:
platform deploy -d -A ru
Ta komenda przebuduje całość wraz z nowym sciagnieciem modulow i uruchomieniem pliku make. (prawdopodobnie bedziesz chcial uzyc tej komendy)
platform deploy -d ru
Ta komenda przebuduje całość, ale moduły z solas2 zostaną niezmienione.
----
Dwie f. hook_update w jednym projekcie - kwestia numeracji
----
Jesli sa dwa tickety ktore dotycza tego samego projektu i obie zmiany wymagaja f. hook_update to mozna:
1. zrobic z tym samym numerem obie zmiany, a potem jak cos bedzie mergowane jako pierwsze to rozwiazac konflikt - preferowane rozwiązanie
2. wstawic identyczny kod z dwoma f. hook_update do obu ticketow i wtedy jesli jest identyczny to nie bedzie zadnego konfliktu
3. zrobic branch pod brancha (ale tu nie znam szczegolow)
----
Test branch - SKLEP
----
Aby utworzyć branch testową na sklepie wpisujemy:
platform te -p xojmvqut5i7jc solas-5401-email-field-type
Jeśli się utworzy to pojawią się linki do sklepu. Należy pamiętać, że te linki i tak nie działają, bo sklep jest w katalogu shop, dlatego zamiast np. takiego linku:
http://test-5401-xojmvqut5i7jc.bc.platform.sh/
należy użyć takiego linku:
http://test-5401-xojmvqut5i7jc.bc.platform.sh/shop
----
Sytuacja w ktorej TB nie bierze pod uwagę hook_update
----
Załóżmy taką sytuację. Pracujesz sobie nad jakąś funkcjonlanością, w której jest hook_update. Następnie tworzysz sobie TB i zmiany są widoczne. Ale jeśli chcesz wprowadzić jakieś dodatkowe modyfikacje to już przy kolejnym tworzeniu TB te zmiany nie będą widoczne. Dzieje się tak dlatego, że TB mimo przebudowy pracuje na starej bazie, wiec ma juz numer twojego hooka wykonany. Zatem, aby zresetowac numery hook upateow nalezy w konsoli (bedac na branchu ticketa nad ktorym pracujemy) wpisac:
platform sync
I dla kodu nalezy odpowiedziec nie, a dla data (bazy danych) nalezy odpowiedziec tak.
Lepiej od razu zrobic commit i push zmian, a dopiero potem platform sync, bo inaczej trzeba bedzie robic rebuild 3 razy (platform sync (1), commit i push (2), znowu platform sync(3)).
----
usuwanie i ponowna budowa testowego branch w sklepie na pl.sh
----
W bcshop:
1. platform environment:delete -p xojmvqut5i7jc -e test-5680
The environment test-5680 is currently active: deleting it will delete all associated data.
Are you sure you want to delete the environment test-5680? [Y/n] y
Delete the remote Git branch too? [Y/n] y
Deleting environment test-5680
Waiting for the activity mm3lsldgrqm4g (Dawid Nawrot deactivated environment test-5680):
No package to build: environment is inactive.
Deleting environment xojmvqut5i7jc-test-5680.
[============================] 1 min (complete)
Activity mm3lsldgrqm4g succeeded
Deleted remote Git branch test-5680
2. platform te -p xojmvqut5i7jc solas-5680-marketing-default-statement
wynik: linki do sklepu
Teraz w sites/shop:
na qa: git pull
platform checkout test-5680
jesli w katalogu sites/shop jest pusty plik project.make to go usuwamy
jesli sklep jest w katalogu sites/shop/shop to w tym katalogu w pliku project make zamiast qa wpisujemy nazwe swojego branchu np.
nastpenie git commit i git push origin test-0000
powinien zbudowac sie nowy testing branch
----
Lokalne testowanie zmian wprowadzonych przez innego uzytkownika na SOLAS2
----
Jesli chcemy przetestowac zmiany jakiegos uzytkownika lokalnie, bo z jakigos powodu pl.sh nie dziala czy cos to robimy tak:
1. machujemy sobie lokalna branch z branchem zdalnym na SOLAS2, a robimy to tak:
- przechodzimy na branch qa
- sciagamy najnowsze zmiany
- tworzymy branch z poziomu qa przez: git checkout -b nazwa_branchu_taki_jak_zdalny, np.: git checkout -b solas-0000-test
- juz jestesmy na odpowiednim branchu, wiec robimy: git pull origin nazwa_branchu_taki_jak_zdalny np.: git pull origin solas-0000-test
- przy komendzie git diff qa..solas-0000-test powinnismy zobaczyc tylko te zmiany, ktore dotycza tego branchu
3. przechodzimy do dowolnej lokalnej strony i mozna sprobowac juz sprawdzic czy dziala.
4. jesli nie dziala to mozna wyczyscic cache, moze sa jakies hooki, ktore wymagaja odswiezenia
5. jesli nadal nie dziala to przebudowujemy cala strone (czyli przechodzimy na qa i platform deploy -d -A fr)
zmiany powinny byc widoczne.
----
Budowanie środowiska testowego na lokalnej stronie, jesli zmiany byly wprowadzone w SOLAS2
----
Załóżmy, że pracujemy na branchu solas-0000-dupa
1. Jesli mamy juz caly kod napisany w SOLAS2 i jest zrobiony PR to przechodzimy do wybranej lokalnej strony np. cd ~/sites/fr
2. Ściągamy najnowsze zmiany w qa
3. Tworzymy branch testową np. git checkout -b test-0000
4. W pliku project.make wprowadzamy zmiany i wpisujemy swoj branch, zamiast qa wpisujemy: solas-0000-dupa
5. Git status
6. git commit -am "test build"
7. Git push origin test-0000
8. Tutaj pojawi sie informacja, ze tylko administratorzy moga tworzyc branche
9. Wpisujemy: platform branch test-0000 qa
10. Uruchomi sie tworzenie testowego branchu, ale jeszcze bez widocznych zmian.
11. Nastepnie git push origin test-0000, ta komenda jeszcze raz nam uruchomi build, ale tym razem majac wprowadzona nazwe branchu w pliku project.make odbuduje strone ze zmianami ze wspomnianego branchu.
----
Zmiany w CSS
----
Jesli pracujesz nad jakims ticketem typu SUI, np. SUI-152 i zrobisz zmiany, commit i push, a nastepnie te zmiany przejda i zostanie zrobiony merge to i tak nie beda widoczne dopoki Vin lub Simon nie zrobi rebuildu i nowego releasu tych zmian css-owych. Nowy build i relese jest robiony na żądanie, wiec trzeba się z ktoryms z nich skontakowac, aby taki zrobil. Jesli nie chce to napisac w komentarzu do Rengin, ze potrzebny jest nowy release.
Tak naprawdę to chyba Mark się zajmuje nowym releasem, ale zeby to zrobic to nie jest takie proste, bo to musi przejsc jakies testy i tak dalej, wiec lepiej dodac zmiany w lokalnym pliku css, a potem i tak ktos doda to do SUI. Tutaj mark mniej wiecej to wyjasnil:
Dawid Nawrot If you need to get something out without wanting to wait for a SUI release the best thing to do is to add it in solas-ui-overrides.css in the theme. It's not ideal but it's somewhere to put it and I try and use that file as a 'staging area' of stuff that needs to go back into SUI and I usually try and clear out that file when we do a SUI version bump.
Don't get me wrong, if we can do it straight away in SUI (as we did then) then it's all good but often it's not possible/practical as the two releases are not tied together (they are separate products) and if it's a breaking change then it stops us having to version bump SUI for Drupal's sake, which can be a pain due to the sub themes like Shakey also requiring a version bump (version sits in the .info file). Obviously it's not an issue here but just an FYI. It's almost like using proper Bootstrap, we might add a fix in our local override stylesheet then report a bug to Bootstrap and when they fix it we can remove our fix. I.E we wouldn't wait for Boostrap to fix our bug if you know what I mean.
---
Update VM
---
Różne tagi służą do różnych procesów i tak np. tag 3.3.1-PHP56 jest tylko do update. Z tego tagu nie da się zbudować od nowa VM. O to do czego służy tag należy zapytać Vincenzo. Jeśli jest potrzebny update VM-a to pytasz, ktory tag updateuje VM, wchodzisz na gihub i tam przełączasz się na niego, następnie klikamy na releases i przy tym tagu powinna byc instrukcja. Acha, update wykonujemy w katalogu istniejącego VM-a.
i teraz tak, bedac w katalogu psh-vm wpisujemy git pull tym samym pobierzemy wszystkie nowe branche / tagi. Aby przelaczyc sie na dany tag wpisujemy git checkout v3.1.2-PHP56.
No i dalej wg instrukcji z release notes - z reszta git checkout .. tez jest w release notes.
New solas site rollout
1. W pierwszej kolejności ixis przygotowuje środowisko.- w ramach przygotowania powinniśmy dostać: master, qa, stage i snapshot. W ramach snapshot powinniśmy mieć zdefinionwane 4 zmienne: disk = 2048 (inherited), group = solas (inherited), mysqldisk = 2048 (inherited), site_code = russia-music
Teoretycznie powinniśmy pracować na branchu master, ale nie miałem uprawnień do pushowania do master, mimo że Simon je podobno ustawił. To jest problem z vagrantem i konfiguracją gita. Z poziomu Maca bez problemu można się logować do master i pushowac do master, tak że rollout powinien być w zasadzie zawsze prowadzony z poziomu maca.
2. Jeśli mamy przygotowany projekt na platform.sh i lokalnie platform projects potrafi go wylistować to musimy go sklonować. Nie robimy platform deploy, bo to nie zadziała na takim projekcie. Natomiast musimy zrobić platform get -p ID_projektu i to w katalogu sites/ (w zasadzie w katalogu release_sites). Zapyta nas do jakiego katalogu ma być sklonowany projekt i zasugeruje nam katalog. Wprowadzamy nazwę taką jaka nam pasuje np. 'russia-music' i repo jest sklonowane.
3. Wchodzimy do katalogu i łatwo zauważyć, że jest zupełnie inna struktura plików niż w przypadku istniejącej strony. Musimy go doprowadzić do stanu standardowej strony (czyli w kat. site powinna znaleźć się większość danych, itd). W tej chwili jestesmy na branchu master - można spróbować zrobić jakiś push, jeśli nadal będzie kwikał o brak uprawnień do pushowania do master to robimy nowy branch od master i na nim pracujemy (ale z poziomu Maca nie powinno byc problemów). Dodajemy katalog /site i tam przenosimy to co nam się przyda, to co nie to usuwamy i możemy też skorzystać z site-template, który znajduje się w solas2/sites/site-template. Jak już wszystko ustawimy jak trzeba to robimy commit i push - niestety trzeba to robić trochę na ślepo, bo nie ma możliwości przetestowania tego lokalnie - w każdym razie ja nie wiem jak to zrobić. Po commit i push zobaczymy, że środowisko jest nieaktywne (inactive) (komentarz dodatkowy: to niekoniecznie tak jest, jesli faktycznie byl robiony branch od master to tak, ale jak sie robi push do master to powinno być ok). Tutaj była potrzebna pomoc Simona, żeby aktywował środowisko. Okazało się również, że repozytorium solas2 profile nie mogło się zaciągnąć, bo IXIS zapomniał dodać ssh key do projektu. To dodał Simon manualnie. Dzięki temu jak już środowisko jest aktywne to można wbić się na platform ssh -e branch i zainstaować stronę. Ale zanim to zrobimy z dates usuńmy 'short' - jeśli tego nie zrobimy instalacja się wywróci. Najlepiej to zrobić z opcją --verbose np.:
drush si -y --verbose solas2
Dzięki temu będziemy mieli cały output na ekranie. Jesli wszystko poszło ok to w następnym kroku dodajemy datę short, hook_update i robimy push. Hook update powinien wykonać się w trakcie przebudowy, nie ma potrzeby wchodzenia przez ssh i uruchamiania drush updb. W ten sposób zainstalowaliśmy drupala na master. Teraz należy zrobić sync danych i plików na pozostałe branche. I tutaj troche dziwna rzecz, a mianowicie sync na snapshot był nieaktywny. Dopiero po jakichś 5 minutach zrobił się aktywny, więc trzeba chwilę poczekać. A jak już zsynchronizujemy snapshot to reszta idzie z górki (qa i stage). Na koniec można zrobić platform deploy lokalnie, powinno wszystko działać. W kadym razie tak było w przypadku active-citizens.
----
Rollout sklepu
----
Aby stworzyć rollout sklepu dla danego kraju bedziemy potrzebowac dwoch lub trzech branchy. Pierwsza z nich to zmiany globalne w bcshop. Druga to zmiany dla testing branch w katalogu /sites/shop. Trzecia natomiast, najistotniejesza - tam gdzie jest wiekszosc konfiguracji dla danego kraju to katalog danego kraju np. /sites/br (Brazil). I teraz tak, jeśli story ma numer 5555 to:
- branch w bcshop powinna miec nazwe: solas-5555 (a w zasadzie to chyba przydaloby sie dodac jeszcze opis tak standardowo)
- branch w sites/shop powinna miec nazwe: solas-5555-shop (to jest TB) - ja bym to nazwal test-5555, no ale...
- branch w sites/br powinna miec nazwe: solas-5555-shop (a to bym nazwal solas-5555)
Prawdopodobnie nie trzeba będzie wprowadzać żadnych zmian do bcshop, to jest podobna zmiana do sui enable, wiec teoretycznie powinna się zamykać w obrębie zmian dotyczacych kraju. Poki, co najlepszym przykladem zmian jest solas-5826, wiec jak się przepniemy na tą gałąź wg powyzszego schematu to powinniśmy dostać kompletne rozwiazanie dla uruchomienia sklepu (rollout) dla Brazylii. Póki, co tam jest jeszcze problem z platnosciami, bo nie dzialaja, ale zakutalizuję ten opis w momencie jak nie bedzie juz zadnych problemow.
Generalnie zmiany lokalne (br) sa wprowadzane w katalogu shop (ktory z reszta jest tworzony) czyli /sites/br/shop (dlatego tez strony zostaly przeniesione do sites/br/site zeby nie mieszaly sie pliki. Oto lista plikow, ktora zostala zmieniona:
.platform/local/project.yaml
.platform/routes.yaml
.platform/services.yaml
shop/.platform.app.yaml
shop/CHANGELOG-QA
shop/libraries/README.txt
shop/modules/README.txt
shop/modules/custom/bcshop_install/bcshop_install.info
shop/modules/custom/bcshop_install/bcshop_install.install
shop/modules/custom/bcshop_install/bcshop_install.module
shop/modules/features/bcshop_site_settings/bcshop_site_settings.features.field_instance.inc
shop/modules/features/bcshop_site_settings/bcshop_site_settings.features.inc
shop/modules/features/bcshop_site_settings/bcshop_site_settings.features.language.inc
shop/modules/features/bcshop_site_settings/bcshop_site_settings.info
shop/modules/features/bcshop_site_settings/bcshop_site_settings.module
shop/modules/features/bcshop_site_settings/bcshop_site_settings.strongarm.inc
shop/modules/features/bcshop_webtrends/bcshop_webtrends.features.inc
shop/modules/features/bcshop_webtrends/bcshop_webtrends.info
shop/modules/features/bcshop_webtrends/bcshop_webtrends.module
shop/modules/features/bcshop_webtrends/bcshop_webtrends.strongarm.inc
shop/php.ini
shop/project.make
shop/settings.php
shop/themes/README.txt
----
Pokaz liste zmienionych plikow w obrebie branchu
----
Jesli jestes na branchu np. solas-5555 to aby pokazac sama liste (bez zmian / kodu) plikow nalezy wpisac: git diff --name-only qa
I w ten sposob wszystkie pliki zostana wylistowane.
----
Jak usunąć całkowicie istniejący kraj (lokalnie)
----
1. Usuwamy bazę danych, bądź obie, jesli jest sklep np.: drop database psh_itd
2. Usuwamy pliki, bedac w katalogu sites wpisujemy: rm -rf pl
gdzie pl to nazwa katalogu do usuniecia. Teoretycznie po tym zabiegu jak sobie wpiszemy platform deploy -d -A -p [project_id] wszystko powinno zadzialac jak nalezy.
----
Restart REDIS-a przy bledach
----
Jesli z jakiegos powodu podczas deploymentu lub czyszczenia cache redis się wysypie, zaczną się pojawiać błędy typu:
EVAL failed: ERR Error running script (call to f_480b498a45897bea144749414832ecbca2df61d8): @user_script:3: @user_script: 3: -MISCONF [error]
Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are
disabled. Please check Redis logs for details about the error. PhpRedis.php:137
to nalezy zrestartowac serwer komendą: sudo service redis-server restart
----
Uruchamianie sklepu
----1. Najlepiej skopiowac caly katalog /shop do danego kraju i na nim wprowadzac zmiany
2. Ponadto nalezy wprowadzic zmiany w .platform/routes.yaml oraz .platform/services.yaml
3. Po wprowadzeniu wszystkich niezbednych zmian nalezy zrobic git commit i git push.
4. Oczywiscie system bedzie krzyczal, ze nie moze stworzyc zdalnego branchu
5. Nalezy go stwrzoyc komenda: platform branch solas-0000-mx-shop qa
6. Nastepnie jak juz sie stworzy branch to wysylamy zmiany komenda: git push origin solas-0000-mx-shop
7. Jak juz wszystko sie przebuduje to wchodzimy na platform.sh i odwiedzamy strone, po wpisaniu /shop powinien nas przekierowac do install.php?profile=bcshop lub cos podobnego.
8. Oznacza to tylko, ze jest wszystko ok tylko nalezy zainstalowac sklep, zatem wracamy do konsoli i wpisujemy: platform ssh -A shop
9. Zaloguje nas po ssh do branchu na ktorym jest sklep.
10. Nastepnie nalezy wejsc do katalogu /shop i zainstalowac sklep komenda: drush site-install
11. Po poprawnej instalacji (bledy dotyczace wysylania maili nalezy pominac) pojawi nam sie info, ze sklep jest zainstaloway.
12. drush -y cc drush
13. drush -y fra
14. drush -y cc all
15. drush -y upwd admin --password='6603Q~140z3962ia4.9gnf9On'
16. Nastepnie nalezy wyczyscic redis. I tu jest troche problem, bo nie wiadomo jak wyczyscic redis dla sklepu. W kazdym razie redis dla strony czyscimy w nastepujacy sposob:
17. W katalogu /shop wpisujemy: redis-cli -h redis.internal
18. W tym momencie powinien nas polaczyc z usluga redis, czyli konsola powinna wygladac tak: redis.internal:6379>
19. Wpisujemy: redis.internal:6379> flushdb
20. W odpowiedzi dostajemy OK. Czyli redis wyczyszczony. Wiecej informacji tutaj: https://docs.platform.sh/configuration/services/redis.html na dole przyklad. Niestety dla sklepu to nie dziala, mimo ze moim zdaniem powinno. W ten sposob powinno wygladac logowanie: redis-cli -h shopredis.internal wg tej dokumentacji.
21. Na serwerze juz mamy wszystko. Teraz pozostaje zrobic deployment lokalnie. W pierwszej kolejnosci trzeba sciagnac dumpy bazy danych. Robimy to tak: platform drupal:db-sync -e solas-5835-mx-shop
22. Troche to potrwa, bo bazy sa spore. Ta komenda sciaga dump bazy danych do katalogu /tmp tam znajdziemy dwa pliki, ktore sa dumpami baz danych. Wazne, aby oba pliki byly spore, bo zdarzylo mi sie tak, ze w jednym nie bylo struktury bazy. Pewnie wczesniej wykonalem taka komende (przed instalacja) i ponowne wywolanie komendy niczego nie zmienialo. Dlatego, jesli zajdzie taka sytuacja to nalezy usunac te pliki z katalogu tmp i ponownie wywolac komende.
23. Nastepnie w katalogu np. sites/mx wpisujemy: platform deploy -d -A
24. Ta opcja -d wymusi uzycie tych plikow dump bazy danych i zaimportuje je podczas deploymentu.
25. Calosc dziala jak nalezy.
Lista projektow
platform projectsTheme debug
https://www.drupal.org/docs/7/theming/overriding-themable-output/working-with-template-suggestions
drush enable: drush vset theme_debug 1
Homestad laravel - make it work
To nalezy dodac do pliku Vagrantfile do konfiguracji:https://github.com/mitchellh/vagrant/issues/7648#issuecomment-235282382
Jesli z jakiegos powodu domena nie dziala, a na tych ustawieniach nie dziala (przechodzi przez SSH, ale doemny nie dzialaja) to trzeba ja dodac manualnie. W konsoli macox wpisujemy: sudo nano /etc/hosts i na koncu dodjemy nowa linie z zapisem:
192.168.88.88 drupalvm.dev
i powinno dzialac.
Tutaj wiecej: http://davebaker.me/articles/setting-up-a-local-dns-server-on-osx
Konferencja - numer na ktory trzeba dzwonic
00 800 1114 593potem trzeba podac kod, ktory podadza podczas rozmowy i na koncu dodac #
Praca z tiger quiz
Repozytorium znajdziemy w /Users/dn/tigerquiz/tiger-quizGlowny branch nazywa sie master.
Dodawanie nowej funkcjonalnosci:
1. Sciagamy najnowsze zmiany z gita: git pull origin master
2. tworzymy nowa galaz: git checkout -b solas-0000-dupa
2a. wpisujemy npm install (ta komende teoretycznie powinno sie uruchamiac zawsze przy przelaczaniu na inny branch)
3. Wprowadzamy zmiany
4. Robimy commit i push, powinny byc dostepne na githubie.
5. nastepnie wpisujemy w katalogu glownym projektu: npm start
6. Jesli wszystko dobrze pojdzie to powinno pojawic sie: webpack: Compiled successfully. (jesli cos nie dziala to nie wpisujemy kolejnej komendy tylko nalezy znalezc problem i dopiero jak mamy pewnosc, ze sie dobrze kompiluje to przechodzimy do pkt 7)
7. I teraz mozna wpisac: npm run deploy (ta komenda robi deploy na serwerze czyli pliki quizu, ktore sa uzywane na testowych branchach sa juz dostepne, wiec nic wiecej nie trzeba robic tylko wejsc na uprzednio przygotowany branch i uruchomic aplikacje, wszystko powinno dzialac).
Sublime Text 3 - instalowanie rozszerzeń
1. Klikamy w Tools -> Command Palette lub wcistamy command + shift + p2. Wpisumey install package
3. Następnie wyszukujemy pakietu do dodania
4. Instalujemy / Konfigurujemy
Test PHP
<?php
drupal_add_js($source);
print $source;
?>
Test - numery kart kredytowych
Przede wszystkim tutaj: https://github.com/britishcouncil/bcshop/blob/qa/modules/custom/commerce_gopi/README.md
Visa
Number: 4142621111111112
Expiration date: default
CCV: any
Master Card
Number: 5473551111111117
Expiration date: default
CCV: any
Moduły contrib
/sites/pl/.platform/local/builds/php/public/sites/all/modules/DB Sync
platform drupal:db-sync -e solas-5826-shop - ta komenda sciagnie obrazy baz do katalogu tmp
nastepnie robimy platform deploy -d -A zeby zrobic deployment
Kopiowanie z output
proszę: cp --verbose -rf katalog /home/vagrant/sites/ukWebmail
http://webmail.digitaltest.email/username: catch-all@digitaltest.email
password: kbHDxxfX
Tworzenie testowej branchy z poziomu konsoli
Jesli jestes np. w kat. sites/pl na QA i chcesz zrobić testową branch to wpisujesz:platform environment:branch test-6287
