studienprojekt-sdp / time_microservice

Microservice to return the current time
0 stars 0 forks source link

Action um Push abzulehnen wenn docker build failt #1

Open jnhck opened 3 years ago

jnhck commented 3 years ago

Hi,

also ich habe mal ein wenig mit den Actions rumgespielt. Wenn jetzt eine neue Version mit einem Tag wie "v..*" gepusht wird, dann wird automatisch das Image erstellt und auf meinem Dockerhub Repo hochgeladen. Das funktioniert so weit auch alles.

Wenn ich es richtig verstanden habe, sollen wir ja jetzt über die Actions implementieren, dass ein Push abgelehnt wird, wenn docker build failt. Ich habe hier auf Stackoverflow etwas gefunden, wo jemand genau dies machen wollte. Aber angeblich sei es nicht möglich dies über Actions zu realisieren.

Als Alternative wird dort Folgendes vorgeschlagen:

run a CI job on push and restrict the master branch. You can use GitHub Actions to automatically test your code when a pull request is opened and require that all checks pass before it can be merged. Since the master branch cannot be pushed to directly, it wouldn't be possible to avoid the CI job.

@franke94

Sollen wir das so umsetzen? Oder gibt es eine andere Alternative? Oder habe ich evtl. die Aufgabenstellung falsch verstanden? :smiley:

Vielen Dank im Voraus.

franke94 commented 3 years ago

Hallo zusammen!

Also, grundsätzlich habt ihr den Gedanken absolut verstanden. Ich muss zugeben, dass ich mich im Moment selbst erst in Actions einarbeite und damit noch nicht so super viel Erfahrung habe.

Aber: grundsätzlich kann man mit Actions ja "Terminal-Befehle" ausführen. Ein passender Befehl wäre ja:

Docker build . -t name

Ihr könnt ja mal schauen, ob ihr das eingebunden bekommt.

Grüße

PS: Hackathon-Werbung :P ;)

jnhck commented 3 years ago

Mmh, aber wenn ich die Action aktiv werden lasse bei Push, dann wird alles was ich in der Action beschreibe, leider erst nach dem Push ausgeführt, d.h. der Push ist zu dem Zeitpunkt dann schon geschehen. Den Container zu bauen und hochzuladen nach dem Push ist kein Problem, das funktioniert ja bereits.

Noch eine andere Sache: die WorldTimeAPI braucht leider teilweise 5-10 Sekunden bis sie eine Antwort sendet. Ich habe eine andere API ausprobiert, da bekommt man eine Antwort in <1 Sekunde, aber dafür hat man nur 1000 Anfragen am Tag zur Verfügung. Wird diese Anzahl für unsere Zwecke reichen? Oder wäre die unlimitierte, aber langsamere API die bessere Wahl?

EDIT: Gibt es außer dem Wetter-Microservice noch weitere, die wir erstellen können?

franke94 commented 3 years ago

Hey, entschuldigt die späte Antwort! Also ihr habt natürlich recht, der Push wird ausgeführt und bleibt natürlich auch dann ausgeführt, wenn die Action schiefgeht. Da hab ich mich missverständlich ausgedrückt! Wenn man verhindern wollte, dass fehlerhafter Code in den main gepusht wird, müsste man den Code erst in einem anderen branch pushen, dann die Action ausführen lassen (um den Code zumindest im groben zu testen) und dann die branches mergen.

Zur API: Gerne könnt ihr auch die andere API einbinden. Mit 1000 Anfragen sollten wir erstmal klar kommen. Ich hatte die nur als erstes gefunden und deshalb damit rumprobiert.

Ihr könnt gerne noch weitere Services bauen. Im Moment geht es ja vor allem darum, dass wir (also mich eingeschlossen!) die Arbeit mit Microservices, APIs und Docker lernen und ein bisschen Erfahrung sammeln. Eine Idee (die aus unserem Themenkomplex stammt) wäre zum Beispiel die Abfrage von Pegelständen von Flüssen.

Grüße!

jnhck commented 3 years ago

Die Branch-Protection funktioniert nun auch so wie sie soll. Man kann also nicht mehr direkt auf Main pushen , sondern muss mit PR arbeiten.

branch_protection

und

branch_protection2

Der PR kann anschließend nicht gemerged werden, wenn der Status Check (der aus dem Bau des Images und dem Hochladen auf Dockerhub besteht) fehlschlägt.

branch_protection3

->

branch_protection4