Tenkte jeg skulle lage en ny versjon av node-express basert på Node 12, men ble litt forvirra over versjoneringsopplegget her. Nyeste tag på Docker Hub er "9-common", men den er det ingen spor av i git tags eller i automated builds-historien. Har 9-common blitt pushet manuelt? Hvis jeg pusher en ny git tag "node-express-12.2.0" vil da imaget automagisk bli tagget med 12.2.0? @linemos

Lage workflow som bygger PRs, og ikke tillate merging før den er grønn

Dette er en autogenerert issue, laget av et skript som går gjennom alle NAV sine kodebaser på Github og gjør diverse sjekker. Her er en liste over ting som kan endres for at kodebasen skal bli enda bedre!

Spørsmål og svar

Jeg har meninger om disse rådene - kan jeg komme med tilbakemeldinger?

Skriv i vei, på Slack-kanalen #open-source.

Kodebasen vår er ikke open source, derfor er det ikke noe poeng

Selv om koden i dag ikke er åpen for innsyn, så ta høyde for at den kan komme til å bli det i fremtiden. Uansett så vil forbedringene være til hjelp, enten kodebasen er åpen eller ei!

Hvem har ansvaret for å fikse det her?

Det er i utgangspunktet den/de/teamet som eier kodebasen som må gå gjennom.

Haster det?

Ikke egentlig. Men det hadde vært fint om det ble gjort, innen et par uker kanskje?

Huff, dette ble litt for mye jobb. Vi har ikke tid! Kan dere gjøre det for oss?

Det er greit. Bare skriv "kan dere gjøre det for oss?" som svar på denne issuen. Så kan vi gå gjennom sakene senere med et annet skript, og gjøre endringene automatisk!

https://github.com/nais/baseimages/blob/master/java-10/Dockerfile#L7
https://github.com/nais/baseimages/blob/master/java-11/Dockerfile#L7
Locale no_NB does not exist.

ENV LC_ALL="no_NB.UTF-8"
ENV LANG="no_NB.UTF-8"

should be

ENV LC_ALL="nb_NO.UTF-8"
ENV LANG="nb_NO.UTF-8"

There is a risk that the runtime environment defaults to ASCII if not explicitly told to use UTF-8

See https://github.com/Yelp/dumb-init

Hvis en applikasjon f.eks. kobler seg til to databaser;

oracle/prod/database1.properties
USERNAME=foo
PASSWORD=foo

oracle/prod/database2.properties
USERNAME=bar
PASSWORD=bar

Her vil miljøvariablene USERNAME og PASSWORD kanskje settes til bar - den ene konfigurasjonen overskriver konfigurasjonen til den andre. Dette kunne vi kanskje ha løst ved prefiksing: ORACLE_PROD_DATABASE1_USERNAME og ORACLE_PROD_DATABASE2_USERNAME?
Den løsningen er ikke optimal, fordi det vil bli forskjellige navn på miljøvariablene fra miljø til miljø, og så må det håndteres på et vis.
En annen løsning er å lage en mapping mellom navn på fila og hvilket prefiks den skal ha.

Kanskje det enkleste er å ikke lese inn alle .env-filene som miljøvariabler, men kun lese inn "hovedfila" til hver app? Så kan applikasjonene selv lese inn hvis de trenger andre stier?

(I'm sorry this issue is written in Norwegian, but it's generated by a script meant for the navikt organisation. Use Google Translate if you want to know what is written)

Dette er en autogenerert issue, laget av et skript som går gjennom alle NAV sine kodebaser på Github og gjør diverse sjekker. Her er en liste over ting som kan endres for at kodebasen skal bli enda bedre!

Beskrivelse mangler

På Github kan man gi hver kodebase en kort beskrivelse. Denne bør fortelle hva kodebasen heter, og litt om hva den brukes til. (Eksempel: kodebasen "veilarbportefoljeflatefs" har beskrivelse "Oversikt for veiledere over oppfølgingsbrukere".)

Kodebasen mangler en CODEOWNERS-fil

Dette er en fil som skal ligge i rotkatalogen, og angir hvilket team som eier kodebasen, på et maskinlesbart format. Den enkleste varianten, som vil holde for de fleste, er å ha en CODEOWNERS-fil som ser slik ut: (Merk at det skal være asterisk/stjerne foran navn på teamet!)

* @nais/teamnavn

Gyldige teamnavn på Github er:

• @nais/aura (aura)
• @nais/bots (bots)

Her er en oppdatert liste over team i Github.
Mangler teamet deres i lista? Ta kontakt med noen i Core-teamet på Github, så kan de opprette et team til dere.

Hvis det trengs spesielle tilpasninger, så ligger det mer dokumentasjon om CODEOWNERS-filformatet her:

https://help.github.com/articles/about-codeowners/

Forslag: Bruk rebasing av pull requests, for å unngå merge commits i git-loggen

Ikke alle er enig i at merge commits skaper støy i git-loggen. Så dette er valgfritt. Men for de som synes det, så er det mulig å slå på en funksjon slik at alle pull requests gjøres med rebase i stedet for merge - da får man en renere git-logg.

For å endre dette, går man inn på Settings-panelet til Github-repoet, under avsnittet "Merge button" og slår av "Allow merge commits".

Forslag: Beskyttelse av master-branchen

Hvem som helst (av utviklerne i NAV) kan pushe til master-branchen i denne kodebasen. Det kan åpne opp for sårbarheter. For det første vil det en gang i blant skje uhell - utviklere commiter og pusher til en branch for å lage pull request, men så pusher de ved et uhell rett til master-branchen. Det åpner også opp for at noen som har tatt kontroll over en utviklerkonto på Github (eller en utro tjener) kan pushe kode rett til master-branchen og deploye direkte til produksjon, på egen hånd. (Kall det gjerne spekulativt, men det er en mulighet.)

Hvis man ønsker å gjøre noe med det, kan man gå i Settings-panelet til Github-repoet, velge "Branches", og under "Protected branches" sette opp master som protected.

Det er vel opp til teamet å bestemme selv nøyaktig hva kriteriene for push/merge til master skal være, men her kan man for eksempel legge inn krav om grønt bygg før merge, og/eller man kan kreve at koden må ha vært godkjent i code review av minst x antall utviklere fra teamet som eier kodebasen. Man kan også konfigurere at kun medlemmer av teamet som eier koden skal kunne merge pull requests.

Spørsmål og svar

Jeg har meninger om disse rådene - kan jeg komme med tilbakemeldinger?

Skriv i vei, på Slack-kanalen #open-source.

Kodebasen vår er ikke open source, derfor er det ikke noe poeng

Selv om koden i dag ikke er åpen for innsyn, så ta høyde for at den kan komme til å bli det i fremtiden. Uansett så vil forbedringene være til hjelp, enten kodebasen er åpen eller ei!

Hvem har ansvaret for å fikse det her?

Det er i utgangspunktet den/de/teamet som eier kodebasen som må gå gjennom.

Haster det?

Ikke egentlig. Men det hadde vært fint om det ble gjort, innen et par uker kanskje?

Huff, dette ble litt for mye jobb. Vi har ikke tid! Kan dere gjøre det for oss?

Det er greit. Bare skriv "kan dere gjøre det for oss?" som svar på denne issuen. Så kan vi gå gjennom sakene senere med et annet skript, og gjøre endringene automatisk!

Burde vi ha kjørt en sikkerhetssjekk av imagene, feks vha Trivy?

På Travis blir alle images bygget hver dag, og nye images lastes opp til Docker Hub. Uavhengig av om det er endringer i repoet. Dette er vel unødvendig, og kan være forvirrende ved feilsøking ("skyldes denne feilen at jeg har fått et annet parent-image?")

Er det noen grunn til at det bygges daglig?

This is printed at startup with the run script. Has something to do with how bash works and the password prompt maybe?

Enter keystore password: + exec java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Djava.security.egd=file:/dev/./urandom -Dspring.profiles.active=nais -Djavax.net.ssl.trustStore=/var/run/secrets/naisd.io/nav_truststore_keystore -Djavax.net.ssl.trustStorePassword=**secrets** -jar app.jar

Java SE 12 kom ut 19. mars.

Vi behøver et image for dette som støtter all NAV custom oppsett, tilsvarende de andre baseimages.

Se https://hub.docker.com/_/openjdk

JDK11 is currently in the release candidate phase.

A generally available release version is expected 25. September 2018.

One can base the JDK11 image on the JDK10 image.

Stadig flere utviklere bruker macs med apple silicon. Pt. betyr det at alle java-pakker, til dels tunge, kjører på amd64-emulering.

#127 synes antyde at man uansett må bytte java-base, i den sammenhengen hadde det vært kjekt om man også sørget for at java-interpreteren kan kjøre på aarch64/amd64

Si ifra på Slack om dere ønsker noen med M1-mac til å teste. :) Om det er klart hvilken alternativ java-base man migrerer til, kan jeg teste selv.