Rigging av alt som trengs for utvikling tar mye tid. En skal installere _språket_ (*python*, *java*, ...) og en trenger diverse _rammeverk_ (*junit*, *javafx*, ...). Kanskje skal en bruke såkalte _byggeverktøy_ (*maven*, *gradle*, ...) og det må installeres og konfigureres. På toppen av dette kommer selve _IDE-en_ (*VSCode*, *IntelliJ*, *Eclipse*, ...), som må passe til og være konfigurert for det en har installert forøvrig.
...
...
@@ -20,18 +20,19 @@ Jobben med oppsett må jo fortsatt gjøres, men en trenger bare å gjøre det é
Gitpod har integrasjoner med skytjenester som *gitlab* og *github*, så en kan logge inn på og administrere kodelagre der. Gitpod kan også settes opp internt, og NTNU har sin egen gitpod-installasjon tilgjengelig på http://gitpod.stud.ntnu.no, som er integrert med IDI sin *gitlab*-tjeneste på http://gitlab.stud.idi.ntnu.no, så emner som bruker gitlab kan automatisk tilby gitpod som plattform for utvikling.
Alle kodelagre i IT1901 med eksempler og maler er ferdig _gitpodifisert_, se f.eks. https://gitlab.stud.idi.ntnu.no/it1901/javafx-templates[javafx-maler]. Dermed er de lette å bygge videre på, det er bare å trykke på *Gitpod*-knappen. Faktisk kan alle kodelagre på vår gitlab åpnes i gitpod for redigering av filer. Men for å kunne utvikle ordentlig, så må de altså gitpodifiseres vha. konfigurasjonsfilen *.gitpod.yml* og evt. en tilhørende *docker*-fil.
Alle kodelagre i IT1901 med eksempler og maler er ferdig _gitpodifisert_, se f.eks. https://gitlab.stud.idi.ntnu.no/it1901/javafx-templates[javafx-templates]. Dermed er de lette å bygge videre på, det er bare å trykke på *Gitpod*-knappen. Faktisk kan alle kodelagre på vår gitlab åpnes i gitpod for redigering av filer. Men for å kunne utvikle ordentlig, så må de altså gitpodifiseres vha. konfigurasjonsfilen *.gitpod.yml* og evt. en tilhørende *docker*-fil.
En alternativ måte å åpne gitpod på er å skrive inn nettadressen til gitpod-tjeneren (http://gitpod.stud.ntnu.no) etterfulgt av *#* og så adressen til gitlab-kodelageret som skal åpnes, f.eks. `http://gitpod.stud.ntnu.no#https://gitlab.stud.idi.ntnu.no/it1901/javafx-templates`.
== Gitpod-arkitektur
VSCode i nettleseren fungerer nokså likt VSCode lokalt, den har tilgang til et filsystem med kjørebare programmer, og en del av filsystemet utgjør arbeidsområdet til VSCode. Forskjellen er at filsystemet og programmene er inni en virtuell maskin i skyen, og maskina startes opp kun for å kjøre VSCode i nettleseren. Ved oppstart _klones_ kodelageret inn i maskina, og innholdet utgjør altså arbeidsområdet til VSCode. Konfigurasjonen av maskina og evt. oppstartsinstruksjoner leses ut av *.gitpod.yml* på toppnivå i det samme kodelageret.
[.stretch]
image::images/gitpod-arch.png[width=800]
Den virtuelle maskina er _flyktig_, i den forstand at den forsvinner av seg selv hvis en lukker VSCode (eller fanen) eller lar være å bruke den en periode. Arbeidsområdet (og noen andre viktige filer) arkiveres imidlertid, slik at den kan startes opp igjen med i praksis samme innhold. Det blir som om en legger en bærbar i dvale og så vekker den til live igjen. Vanligvis vil en derfor fortsette med et eksisterende arbeidsområde fra hovedsiden til gitpod-tjenesten, i stedet for å starte en ny virtuell maskin med et nytt arbeidsområde fra (gitlab-nettsida for) kodelageret. Det er bare når en endrer oppsettet etter å ha redigert *.gitpod.yml* eller *docker*-fila at en må starte en helt ny maskin.
Som nevnt klones kodelageret inn i den virtuelle maskina, og håndtering av kodelageret blir som ved kjøring på egen maskin, en bruker de vanlige *git*-kommandoene for å synkronisere med gitlab-tjeneren. En er ikke nødt til å lagre unna endringer i arbeidsområdet til tjeneren før den virtuelle maskina legges i dvale, hele arbeidsområdet arkiveres jo, men dersom en jobber med andre eller bruker VSCode i både gitpod og lokalt, så må en jo synkronisere filer via gitlab. Merk også at arkiverte arbeidsområder lagres ikke evig, de kastes etter noen uker uten bruk, så en må bruke git innimellom.
Hvis den virtuelle maskina er riktig satt opp (se under om konfigurering med *.gitpod.yml*), så kan en faktisk kjøre grafiske apper (f.eks. skrevet i JavaFX) og få dem vist inni gitpod eller i et separat nettleservindu. Dette krever at en "slår på" en virtuell grafisk skjerm som er en del av den virtuelle maskina. Se etter tallet 6080 i statuslinja nederst og trykk på det. Da spretter det opp et panel og en kan angi at 6080 (som representerer den virtuelle grafiske skjermen) skal vises i *Preview*-panelet eller i et eget nettleser-vindu.
== Gitpod-bruk i emner
...
...
@@ -54,3 +55,69 @@ Fagstaben i et emne lager en gitlab-gruppe for emnet og semesteret, f.eks. *tdt4
=== Eksamen (!)
Eksamen kan rigges omtrent som et øvingsopplegg, med et personlig kodelager pr. student, med både oppgave og (etterhvert) besvarelse i.
== Gitpod og bruk av git
Som nevnt klones kodelageret inn i den virtuelle maskina, og håndtering av kodelageret blir som ved kjøring på egen maskin, en bruker de vanlige *git*-kommandoene for å synkronisere med gitlab-tjeneren. En er ikke nødt til å lagre unna endringer i arbeidsområdet til tjeneren før den virtuelle maskina legges i dvale, hele arbeidsområdet arkiveres jo, men dersom en jobber med andre eller bruker VSCode i både gitpod og lokalt, så må en jo synkronisere filer via gitlab. Merk også at arkiverte arbeidsområder lagres ikke evig, de kastes etter noen uker uten bruk, så en må bruke git innimellom.
Å komme i gang er i grunnen mest komplisert, fordi utgangspunktet for kodelageret kan være så forskjellig.
=== Jobbe videre med andres kodelager
Hvis en skal jobbe videre med et kodelager som eies av andre, så må en lage en kopi (med eller uten kobling til originalen, med kobling så kalles det gjerne en "gaffel"). En oppretter da et nytt kodelager på gitlab f.eks. på egen bruker eller under en emne-gruppe. Navigér til egen bruker eller gruppa og velge *New project* under *+*-menyen øverst.
image::images/gitlab-new-project.png[width=800]
Lag et tomt/blankt kodelager uten README, fordi hele innholdet skal overføres fra originalen. Hvert kodelager har sin egen adresse som brukes av git. Velg *Clone*-nedtrekksmenyen og kopier *HTTPS*-adressen (se under). Den skal brukes i en git-kommando for oppsett av git inni gitpod.
image::images/gitlab-repo-url.png[width=300]
For å knytte kodelageret inni gitpod til det nye kodelageret på gitlab, skriv inn `git remote set-url origin` etterfulgt av kodelager-adressen fra forrige steg. Dermed vil alle kommandoer som opererer på git-tjeneren (en såkalt _remote_)gå mot det nye kodelageret. Kommandoen `git push -u origin master` brukes først for å overføre alt git-innhold m/historikk til det nye kodelageret sin *master*-grein, og siden kan en bare bruke `git push` for å oppdatere, evt. `git pull` for å hente ned endringer fra tjeneren.
Dersom en vil beholde knytningen til original-kodelageret, så endrer en først navnet
på den opprinnelige kobling til f.eks. upstream med `git remote rename origin upstream`. Så opprettes det en ny kobling til det nye kodelageret med `git remote add origin` etterfulgt av kodelager-adressen fra forrige steg. Da vil vanlig bruk av *git push* og *git pull* gå mot det nye kodelageret, men en kan hente ned endringer fra original-kodelageret med *git fetch upstream* og innlemme dem med *git merge upstream/master* (og være beredt til å håndtere konflikter).
=== Opprette nytt kodelager på gitlab
Dette er i grunnen det enkleste. En bruker samme skjema som over, men velger å lage en README med det samme (om en glemmer det, så kan en lage en README på nettsiden til det nye kodelageret), og etter at kodelageret er opprettet, så åpner man bare gitpod på det nye kodelageret. Merk at selv om en kan åpne gitpod, så er ikke kodelageret automatisk gitpodifisert. Det gjør en ved å opprette *.gitpod.yml* og evt. en *docker*-fil med passende innhold, overføre disse tilbake med *git push*. For at det nye gitpod-oppsettet skal få effekt må en starte gitpod på nytt fra nettsida til kodelageret.
=== Overføre lokalt kodelager til gitlab (og gitpod)
Dersom du sitter med et kodelager lokalt på maskina di (som ikke finnes på gitlab), så kan det åpnes i gitpod ved å først overføre det til et kodelager på gitlab, for så å åpne det i gitpod. Prosessen blir litt som den første varianten over, en oppretter et kodelager på gitlab og angir så at det lokale kodelageret skal knyttes til det nye på gitlab (som en _remote_). Skriv inn `git remote add origin` etterfulgt av kodelager-adressen for det nye kodelageret (tilsvarende varianten over). Dette gjøres selvsagt i terminalen lokalt, evt. inni terminal-panelet i VSCode lokalt.
Til slutt åpnes det nye kodelageret på gitlab i gitpod.
== Gitpod-konfigurasjon med .gitpod.yml og gitpod.Dockerfile (for den dristige)
Den virtuelle maskina konfigures vha. en spesiell fil med navn *.gitpod.yml* og en tilhørende *docker*-fil. Førstnevnte angir bl.a. hvilken *docker*-fil som beskriver alt som skal være ferdig installert i den virtuelle maskina. Det enkleste er å referere til en standard *docker*-fil laget for formålet f.eks. *gitpod/workspace-full-vnc*. Da får en en støtte for en rekke vanlige programmeringsspråk og kan kjøre grafiske apper på en slags virtuell skjerm som vises i gitpod eller et eget nettleser-vindu. Dersom en trenger noe ut over dette, kan en lage sin egen *docker*-fil som angir det som trengs ekstra på toppen av en standard en. Det er litt mye å dekke her, men under vises et enkelt oppsett for å bruke en nyere Java-versjon enn det som er standard i gitpod.
*.gitpod.yml* (styrer oppsettet):
....
image:
file: .gitpod.Dockerfile
tasks:
- init: sdk use java 16.0.1.hs-adpt
....
*.gitpod.Dockerfile* (angir innhold i virtuell maskin):
....
FROM gitpod/workspace-full-vnc
USER gitpod
RUN bash -c ". /home/gitpod/.sdkman/bin/sdkman-init.sh \
&& sdk install java 16.0.1.hs-adpt \
&& sdk default java 16.0.1.hs-adpt"
....
Det viktige her er at
- *.gitpod.yml* refererer til *.gitpod.Dockerfile*
- *.gitpod.Dockerfile* bygger på (ved å referere til) *gitpod/workspace-full-vnc*
- *.gitpod.Dockerfile* kjører en ekstra kommando(linje) som installerer java-distribusjonen *16.0.1.hs-adpt* vha. *sdk*-programmet
- *.gitpod.yml* kjører en kommando for å ta i bruk *16.0.1.hs-adpt* i gitpod-terminal
En kan installere nær sagt hva som helst ved å skrive de riktige installasjonskommandoene inn i *.gitpod.Dockerfile* og ytterligere instruksjoner i *.gitpod.yml*. Det er litt fikkel, men en kommer langt ved å søke etter relevant *docker*-filer på https://hub.docker.com/search?q=&type=image[Dockerhub] og kopiere innhold derfra.
