Python/DevOps

Let's say that you have to log in via ssh into an instance, and you work with GitLab, so you want to keep the private key in GitLab somewhere. Is it secure? Let's see! Custom environment variables You can use custom environment variables. Here you can read more about them (Developers cannot change them, only Maintainers and Owners can). There are two types of variables: Variable (the runner creates an environment variable that uses the key for the name and the value for the value) File (the runner creates an environment variable that uses the key for the name. For the value, the runner writes the variable value to a temporary file and uses this path) It seems that we can use File type for our purpose. We can set up it via API or UI . So, let's do that! Go to project's Settings > CI/CD . There will be Variables section (btw, you can specify variables also per group and even for all projects (in admin panel)). Click Add Variable button and add a variable: Key:

Ostatnio często muszę robić diffy w gicie i zapisywać je do plików. Przykładowa nazwa pliku z diffem wygląda tak: {branch}-{branch/commit}.diff Diffy pomiędzy poszczególnymi commitami nie są mi potrzebne. Aby otrzymać takiego diffa można wykonać komendę git diff {branch/commit} > ~/diffs/{branch}-{branch/commit}.diff . Przykłady: git diff develop > ~/diffs/develop-master.diff git diff 66666 > ~/diffs/66666-develop.diff git diff 18361 > ~/diffs/18361-develop.diff git diff 47529 > ~/diffs/47529-0dbf4fa.diff Jak widać jest trochę pisania.  po co za każdym razem wpisywać katalog w którym ma zostać stworzony plik po co podawać nazwę brancha na której właśnie jesteś (i to dwa razy!) ;) pracuj na gałęziach, których nazwy składają się wyłącznie z cyfr to oczopląsu dostaniesz po kilkunastu takich komendach Dlatego też postanowiłem napisać do tego prostą funkcję w bashu. Założenie było proste, mam podać nazwę funkcji i jako pierwszy parametr przekazać nazwę brancha/comm

Kilka dni temu trafiłem na plugin vim-gitgutter i postanowiłem go wypróbować. W wielkim skrócie plugin odpowiada za pokazywanie w którym miejscu w pliku dokonałeś zmian, coś jak git diff . Korzystam z pathogen , więc aby zainstalować plugin wklepałem: cd ~/.vim/bundle git clone git://github.com/airblade/vim-gitgutter.git I już można się bawić. Posiedziałem nad nim chwilę i naprawdę mi się spodobał, lecz musiałem wprowadzić kilka swoich poprawek :) Po pierwsze, wyłączyłem domyślne pokazywanie różnic, a zbindowałem sobie komendę GitGutterToggle pod <leader>gr . Dzięki temu jak chcę zobaczyć różnicę to wciskam ,gr (klawisz <leader> mam zbindowany pod ","), a jak chcę wyłączyć to wciskam znów to samo. Dodatkowo zbindowałem sobie komendy GitGutterNextHunk i GitGutterPrevHunk odpowiednio pod <leader>d oraz <leader>s . Mogę przez to w łatwy i szybki sposób poruszać się po pliku skacząc z jednej zmiany na drugą. Tak to wygląda w pliku .vimrc :

Jeżeli w swoim repozytorium gita korzystasz z kilku/kilkunastu repozytoriów to po dłuższej chwili zacznie cię mocno irytować taka rutyna: wchodzę w submoduł sprawdzam gałąź, czy jest na master odpalam git pull wychodzę z submodułu Jest na to łatwy sposób. Wystraczy wklepać w konsoli: git submodule foreach git pull Ale uwaga, tutaj niespodzianka ;) Jeżeli dopiero co zassałeś swoje repozytorium w którym masz submoduły, to aby działały musisz najpierw odpalić: git submodule init git submodule update --recursive wszystko się oczywiście wykona, ale submoduły zostaną zaktualizowane do konkretnego commita , którego ustawiłeś wykonując wcześniej git push . Co implikuje to, że nie będziesz miał ustawionej gałęzi w żadnym z submodułów. Submoduł będzie wskazywał na konkretnego commita, a nie na gałąź. git submodule update --recursive Jest to oczywiście normalne i tak powinno to działać! Taka jest idea submodułów. Odwołują się do commita, którego im przypisałeś, a nie do konkre

Submoduły Submoduły, czyli co zrobić, żeby np. na githubie w jednym repo umieścić inne repozytoria, aby wyglądało to tak jak poniżej, a nie tak jak na przykład tutaj . Do czego się w ogóle przydają submoduły i dlaczego powinieneś je stosować? Wyobraź sobie, że tworzysz swoje repozytorium, które do poprawnej pracy wymaga innych, konkretnych repozytoriów gita. I tutaj z pomocą przychodzą submoduły. Dzięki nim twoje repozytorium będzie posiadało informacje o tym, gdzie dany submoduł się znajduje (jego adres) oraz jego ostatnie commit ID. Dzięki takiemu zabiegowi, inni developerzy, którzy sklonują twoje repo (które wykorzystuje inne repozytoria), nie będą musieli się martwić, czy wszystko będzie działało tak jak powinno. Unikniesz przez to czasami dziwnych błędów. Np. ktoś dociągnie zbyt stare repozytorium lub zbyt nowe, albo całkowicie inną gałąź, niż tą które wykorzystuje twoje repo ;) Osobiście póki co, użyłem submodułów w moim repo dotfiles . Dodawanie submodułów Załóż

(Uwaga, zmieniła się nazwa repo powerline-bash, po więcej zapraszam tutaj ) Używasz vima? A używasz w nim  vim-powerline ? Jeśli tak, to czemu nie wstawić sobie powerline do konsoli? Używam tego od pewnego czasu i muszę przyznać, że jest bardzo ciekawym dodatkiem. W czym mi to tak naprawdę pomaga oprócz tego, że widzę aktualną gałąź na której pracuję? Jeżeli zmienię coś w którymś z plików, zmieni się również kolor gałęzi: To samo stanie się, jeżeli pójdzie coś nie tak przy wykonywanych operacjach na repo. Jeśli dodasz plik, który nie jest śledzony przez gita pojawi się "+": Gdy ścieżka do katalogu robi się zbyt długa, powerline zostaje przycięty: I jedna z ciekawszych rzeczy; jeśli lokalne repo różni się od "zdalnego" (nie wiem jak najodpowiedniej to przetłumaczyć na polski) to zostanę o tym poinformowany: Co od razu mówi mi, że przy pull'u dostanę 5 commitów :) Informacje o tym jak podpiąć skrypt pod konsolę znajdziesz tutaj: powerl