[Sayong]

Każdy by tylko darł na niego koty i wypominał kiedy zawiedzie. Nikt nie podziękuje Panowi Jenkinsowi gdy sumiennie wykonuje swoją pracę. Dziękuję pan Jenkins.

#devops #programowanie #heheszki

[yupitr]

@Sayong: Jenkins przecież bardzo spoko jest

[Gennwat]

@Sayong: odkad poznalem sie Gitlab CI, mam nadzieje ze juz nigdy nie trafie do legacy srodowiska z postawionym klocem w postaci jenkinsa

[kucyk]

@Sayong:

[mugenDeath]

@Sayong: Gdy pracowalem z Jenkinsem nienawidzilem go za maintenance, parkour z pluginami, upgrade.

Potem zacząłem pracować z Github Actions, Gitlabem, Bitbucketem, jakimiś #!$%@? CodeGówno od AWS...

Teraz tęsknię za Jenkinsem.

[DoubleAxxis]

@Sayong Hudson FTW (⌐ ͡■ ͜ʖ ͡■)

[MTCO]

@Sayong: O Boże o kur#a

[Leniek]

@Sayong: wąsaty #!$%@?

[some_ONE]

Nikt nie podziękuje Panowi Jenkinsowi gdy sumiennie wykonuje swoją pracę.

@Sayong: Bo to się nigdy nie zdarza

[wcaleniepchamsiewmultikonto]

@Sayong: Jestem w firmie legacy i teraz uzeram sie z tym gownem. W dodatku wszystko leci z parametrow, zadne tam budowanie obrazow dockerowych.

Jak w firmie jest Jenkins to trzeba omijac szerokim lukiem.

[Myzreal]

@Sayong: ja właśnie stawiam tego #!$%@?ńca w kubernetesie w chmurze, ubaw po pachy

[bruuh]

@Myzreal: po co byś stawiał to gówno? postaw Drone CI jak koniecznie musisz self hostować CI ale najlepiej uzyć gitlab CI/actions
jenkins to technologiczny odpad w porównaniu do innych rozwiązań

[Hakamairi]

@wcaleniepchamsiewmultikonto: ale pitolenie, jenkins jest tylko narzędziem zrobisz nim CICD i wpasujesz w swój gitflow i będzie super. Jak jakieś miernoty zrobiły jakieś niby skrypty z lat 90tych na paremetrach i templatach to sami sobie jesteście winni.
Jenkins od wersji 2.coś wspiera nawet dockeryzowanie poszczególnych stage, nie mówiąc o side car.

[bruuh]

@Hakamairi: nawet dockeryzowanie wspiera? no nie gadaj... zaraz mi powiesz że mamy już 2022 rok

[Hakamairi]

@bruuh: no, od 2017go, pod kamieniem siedziałeś ostatnie 5 lat?

[bruuh]

@Hakamairi: nie, siedziałem na gitlab ci gdzie nikt by nawet nie pomyślał że może tego nie być i tam wszystko działa i sie ze wszystkim integruje, a praca z rozbudowana konfiguracja typu child pipelines czy trzymanie konfiguracji dla setek projektów w jednym repo to czysta przyjemność i zarządzaniem tym vs jenkinsem to niebo a ziemia

[Hakamairi]

trzymanie konfiguracji dla setek projektów w jednym repo

@bruuh: przecież to jest antypattern, konfiguracja powinna być częścią projektu, wtedy możesz łatwiej wbudować to w gitflow i customizowac zachowanie per branch bez wycieku logiki.

Poza tym configuration as code to 2016ty w jenkinsie. Próbowałem gitlab runner/ci w 2018 i się poddałem. Wtedy w jenkinsie dało się zrobić o niebo więcej.

Wydaje mi się, że wasze doświadczenia to #!$%@? rozwiązania z korpo i

[bruuh]

przecież to jest antypattern, konfiguracja powinna być częścią projektu, wtedy możesz łatwiej wbudować to w gitflow i customizowac zachowanie per branch bez wycieku logiki.

@Hakamairi: ok jak będziesz miał 10 devopsów którzy mają zarządzać 200 projektami w róznych językach na produkcji rozwijanymi przez 500 devsów to wtedy pogadamy, a tymczasem będę trzymał konfiguracje cicd we wspólnym repo z codeownersem na gitlab-ci.yml żeby mi tam nikt gówna na klaster produkcyjny nie wrzucał

[Myzreal]

@bruuh: typie znajdź se dziewczynę bo z twoich postów tak wali potrzebą akceptacji że aż razi xD

[bruuh]

@Myzreal: to ich nie czytaj?

[Hakamairi]

@bruuh: brzmi jak rozwiązanie forsowane przez infre na cały ekosystem. Dev OPS to powinna być kompetencja normalnych devow albo w zespole.