GitLab 14 met pipeline-editor en wysiwyg-wiki-editor is uit

GitLab heeft een nieuwe versie uitgebracht van het developerplatform. De belangrijkste wijzigingen in GitLab 14.0 zijn definitieve toevoeging van een nieuwe wysiwyg-editor in de wiki's, een nieuwe pipeline-editor, en een Kubernetes-platform.

GitLab 14.0 is volgens de makers gericht op voornamelijk snelheid en veiligheid. De belangrijkste wijziging is dat de pipeline-editor is veranderd. Die nieuwe editor zat in bètafase wel al in GitLab 13.8, maar wordt nu definitief doorgevoerd. Het gaat om een specifieke editor voor CI/CD waar onder andere configuratievalidatie in zit naast een visualizer die veranderingen kan weergeven vóórdat commits worden doorgevoerd.

De Kubernetes Agent is ook definitief doorgevoerd nadat dat in 13.8 was geïntroduceerd. Die moet de bestaande Kubernetes Cluster-integratie vervangen.

GitLab heeft ook een paar nieuwe visuele tools. Een opvallende daarvan is een what you see is what you get-editor voor wiki's, zodat gebruikers geen markdown meer hoeven te gebruiken voor opmaak. In de toekomst komt die Content Editor ook in andere onderdelen van GitLab beschikbaar, maar de makers geven daar geen nauwere tijdlijn voor. GitLab heeft ook de sidebar veranderd, met name door het Operations-menu onder te verdelen in aparte secties. Epics zijn voortaan te gebruiken in 'boards', vergelijkbaar met tools als Trello. Gebruikers kunnen hun epics daarin verslepen via een drag-en-dropinterface.

Reacties (39)

[PainkillA]

hoe vergelijkt gitlab zich met github tegenwoordig? Naar mijn idee is gitlab github ver voorbij wat betreft ci/cd, pipelines en environment management en maakt het zaken als review omgevingen per merge request veel eenvoudiger mogelijk

[GekkePrutser]

Ik vind de UI ook een stuk vriendelijker/toegankelijker. Ben helemaal fan van gitlab geworden Totdat deze ook overgenomen worden door big tech...

[TheVivaldi]

Ik vind de UI van GitLab juist een draak. GitHub is veel overzichtelijker en kost me minder klikken om iets te doen.

En ik werk met beide ongeveer evenveel, dus het is niet een kwestie van dat ik er niet mee kan werken omdat ik alleen GitHub gewend ben.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 00:54]

[GekkePrutser]

Hoezo dat? Wat ik aan GitLab zo handig vind is de sidebar links. Bij GitHub kan je niet direct naar releases vanaf elke willekeurige pagina bijvoorbeeld. Bij GitLab wel. Echt alles is te bereiken vanuit die sidebar.

En ook vind ik het prettiger werken dat er veel meer kleur gebruikt wordt. GitHub is me veel te wit (net als alles van Google tegenwoordig). De kleur geeft een betere scheiding tussen de verschillende onderdelen.

Maar smaken verschillen qua UI natuurlijk.

[alienfruit]

Nou de nieuwe navigatie in 14 is wel jammer vooral de topnavigatie

[WoutervOorschot]

Ik vind gitlab juist een stuk logischer, gewoon al je navigatie in 1 (hamburger) menu aan de zijkant. Bij github ben ik altijd de weg kwijt, met sommige links bovenin en sommigen in een zijbalk rechts.

[ChillinR]

Ik vind pull requests in GitHub veel minder fijn werken en minder overzichtelijk dan merge requests in GitLab. En dat is waar ik verreweg de meeste tijd besteed.

[Blaise]

Ik werk inmiddels 4 jaar met GitLab en heb er veel Mercurial projecten naar gemigreerd. GitLab heeft gigantisch veel functionaliteit, maar is soms ook een beetje rommelig, niet zo robuust, en/of werkt maar voor bepaalde workflows. Ze zijn bijvoorbeeld fan van een eigen git flow die werkt met cherry picking, en als je een andere merge strategie gebruikt kan je lekker gaan sleutelen of handmatig mergen.

GitHub is bezig met een inhaalslag en heeft nu ook GitHub actions (CI), packages, een Docker registry. De nieuwe alles-in-één aanpak die GitLab heeft staat bij GitHub nog een beetje in de kinderschoenen, maar ze zetten het naar mijn idee wel stabieler en flexibeler op.

[ChillinR]

Wat bedoel je m.b.t. mergestrategie? Je kan er drie kiezen in GitLab: merge / rebase + merge commit / rebase zonder merge commit. Alledrie werken in mijn ervaring prima.

[Reactie gewijzigd door ChillinR op 23 juli 2024 00:54]

[Blaise]

Als je dingen wil automatiseren zonder handmatig te mergen of cherrypicken, zoals: een live patch moet zowel naar de live release branch als naar stable. Handmatig mergen of cherrypicken is foutgevoelig want je kan het vergeten of je target per ongeluk de verkeerde branch.

[Reactie gewijzigd door Blaise op 23 juli 2024 00:54]

[alienfruit]

Gitlab is erg beperkt qua automatie van merge requests vergeleken met Github. Github heeft de Checks API mar zoiets heeft Gitlab niet echt en dat is toch wel een misser. Verder is de ondersteuning voor monorep's erg beperkt omdat je je code quality reports zoals junit reports manueel moet combineren omdat Gitlab meerdere bestanden niet ondersteund etc. De private NPM registry is erg onstabiel als je het gebruikt om je eigen private npm packages te installeren. Meerdere keren per dag moet je een job opnieuw proberen omdat je een package niet kan vinden (404s).

De UI is erg ongebruiksvriendelijk als je merge requests wilt doen ook hebben ze sindskort een hoofdnavigatie in de topbalk verstopt achter een knop.

[com2,1ghz]

Ziet er goed uit allemaal. De Azure pipeline editor ziet er ook zo uit. Ben er wel blij mee dat men eindelijk een middenweg gevonden heeft met YAML vs GUI.
YAML vind ik het meest slecht lees en schrijfbaar taal.

[kevinr1]

Apart dat je dat zegt. YAML voelt een beetje aan als de huidige standaard. Ik kan er prima mee werken, en ik vind het wel leesbaar. Wil je anders terug naar XML?

[Reactie gewijzigd door kevinr1 op 23 juli 2024 00:54]

[com2,1ghz]

Liever XML of JSON. Hoef je in ieder geval niet na te denken over hoeveel spaties er zit.
In geval van XML kan je er ook nog eens mooi een XSD op zetten om in je editor ter plekke je configuratie te valideren.

[jelmert]

YAML is een superset van JSON wat het mogelijk maakt om YAML te valideren met een JSON Schema. Editors zoals VS Code en alles van Jetbrains ondersteunen dit ook out of the box.

[armageddon_2k1]

Als het een superset is wel dus zeggen dat het meer features heeft dan JSON wat dus kan betekenen dat je juist niet met een JSON schema alles van een YML kan valideren

[Ventieldopje]

Jawel, YAML is 100% om te zetten naar JSON. Dingen zoals anchors kunnen niet in JSON maar bij het converteren los je die eerst op, geen probleem dus.

Al met al kun je YAML dus prima valideren als JSON.

[Ventieldopje]

YAML is letterlijk een superset van JSON, hoe heeft dat niet met elkaar te maken? Je kan gewoon JSON en YAML door elkaar gebruikein in een YAML document.

[Travelan]

Ja op die logica is Microsoft Word ook een superset van YAML...

[mdgf]

Er is geen directe link tussen microsoft word (wat vroeger een binair formaat was, en later xml, dunno about now) en yaml, een tekst formaat die grotendeels 1-1 compatibel is met JSON, waarbij vertalen heel triviaal is. Yaml heel uitwisselbaar maken met JSON is/was net een selling point.

Lees gerust eens de stukken over json en xml hier: https://yaml.org/spec/1.2/spec.html

[Reactie gewijzigd door mdgf op 23 juli 2024 00:54]

[ajolla]

Ik snap het probleem niet. Indentatie maakt de structuur visueel juist heel duidelijk.

[aikebah]

Dan schrijf je je pipeline in JSON en noem hem .gitlab-ci.yml aangezien yaml zoals @jelmert al zegt een superset van JSON is kun je als je wilt de indentation-for-scope vervangen door een explicit scoping in json stijl. Wat voorbeeldjes vind je bijvoorbeeld op https://medium.com/@kasun...curly-braces-3c05ae8700ce

[UPPERKEES]

In de meeste text editors kan je toch gewoon spaces/tabs configuren? Ik heb dat in ieder geval wel in vim. Dan hoef je er helemaal niet meer over na te denken. Zelfde met Python. GUI tools kunnen het ook, zoals Gedit. Geen idee wat je gebruikt, maar dat zal vast ook mogelijk zijn op andere platformen.

[Freeaqingme]

Json? Da's het meest belabberde formaat om configs in te schrijven mijns inziens: al was het maar omdat je er geen comments in kwijt kan. Json is leuk voor m2m communicatie waarbij aan weerzijden schemaless met weaktyped talen gewerkt wordt. Voor al het andere zijn m.i. betere formaten.

En ja, er zijn schema's voor json, er zijn extensies die comments ondersteunen in json, maar dat is out of spec en er later een beetje bij bedacht.

[jannesbeterams]

Ik in ieder geval niet!

[roelboel]

Dat is niet apart, YAML wordt universeel gehaat door devs die voorbij het "hello world" stadium zijn. Ja, als XML je referentie is lijkt het een verlichting. Zodra je iets niet-triviaals doet begint YAML met al z'n indentatie, complexiteit, ambiguïteiten en vreemdigheden erg vervelend te worden. Heb je ooit gehoord hoeveel lol iemand had een niet-triviale Helm Chart of k8s manifest te schrijven? JSON wil je als mens niet met de hand editten (geen comments, altijd geneuzel met trailing commas, etc.). TOML lijkt wat aan populariteit te winnen, maar is ook niet de oplossing. Er is vooralsnog geen oplossing.

[thePiett]

Waarom is er voor een WYSIWYG editor gekozen? Markdown werkt naar mijn mening prima en WYSIWYG editors zorgen vaak voor vernaggelde opmaak.

[JanHus]

Als je de release notes had gelezen dat had je gezien dat je gewoon markdown kan blijven typen in dezelfde editor.

Ik vind dit juist een goede ontwikkeling omdat ook minder technische mensen nu beter gebruik kunnen maken van GitLab.

[JanHus]

Artikel klopt ook. Het hoeft niet, maar het kan wel.

[watercoolertje]

Ik krijg hem nog niet te zien op gitlab maar de meeste WYSIWYG editors hebben gewoon een mogelijkheid tot editen van de source en dus gewoon markdown, want onder aan de streep is het nog gewoon MD wat je aan het schrijven ben ook al zie je nu het resultaat

[Reactie gewijzigd door watercoolertje op 23 juli 2024 00:54]

[webfreakz.nl]

Ik ben recent begonnen met leren over Kubernetes, maar wauw wat een grote wereld is dat.... Zijn mensen hier daar bekend mee en hebben het ingezet? Leuke materie hoor, maar die learning-curve klinkt behoorlijk stijl.

[JanHus]

Off-topic maar ik zou je kunnen aanraden om eerst wat te leren over docker. Heb zelf de introducties hieronder gedaan er erg tevreden over.

Docker: https://www.udemy.com/course/learn-docker/
k8s: https://www.bretfisher.com/kubernetes-mastery/

[Arrogant]

Ter aanvulling op @JanHus :
Echte instapintroductie: Docker - Tutorial van thenewboston (YouTube)

[delphium]

Ik ben hier jaren terug eens mee begonnen als een leuke self hosted GUI voor mijn git-projectjes. Inmiddels is het zo zwaar overkill voor wat ik doe, dat ik weer ben teruggegaan naar simpele bare repo's met ssh.
Wel ongelooflijk wat een progressie dat project heeft doorgemaakt. Mooi voorbeeld van hoe open source goed kan werken.

[DizzyVacation]

Moet je misschien eens naar Gitea kijken, lightweight, simpel en toch een mooie UI voor je repositories.

[delphium]

Nee, ik ben toch al meer van de cli. Ik ben helemaal tevreden met mijn ssh-repo's.

[SuperDre]

Oh wysiwiyg voor wiki is heerlijk, hopelijk ook ondersteuning voor mermaid diagrammen oid.