Go εργαλεία & GitLab - πώς να κάνετε Συνεχής ολοκλήρωση όπως ένα αφεντικό

Φωτογραφία από τον Todd Quackenbush στο Unsplash

Στην Pantomath, χρησιμοποιούμε το GitLab για όλες τις εργασίες ανάπτυξης. Ο σκοπός αυτού του εγγράφου δεν είναι να παρουσιάσει το GitLab και όλα τα χαρακτηριστικά του, αλλά να εισαγάγει πώς χρησιμοποιούμε αυτά τα εργαλεία για να διευκολύνουμε τη ζωή μας.

Τι είναι λοιπόν αυτό; Να αυτοματοποιήσετε όλα όσα σχετίζονται με το αναπτυξιακό σας έργο και να σας επιτρέψει να εστιάσετε στον κώδικα σας. Θα καλύψουμε το χνούδι, τις δοκιμές μονάδας, τον αγώνα δεδομένων, τον απολυμαντικό μνήμης, την κάλυψη κώδικα και την κατασκευή.

Όλος ο κώδικας που εμφανίζεται σε αυτήν την ανάρτηση είναι διαθέσιμος στη διεύθυνση https://gitlab.com/pantomath-io/demo-tools. Έτσι, μπορείτε να πάρετε το αποθετήριο και να χρησιμοποιήσετε τις ετικέτες για να περιηγηθείτε σε αυτό. Το αποθετήριο θα πρέπει να τοποθετηθεί στον φάκελο src του $ GOPATH:

$ go get -v -d gitlab.com/pantomath-io/demo-tools
$ cd $ GOPATH / src / gitlab.com / pantomath-io / demo-εργαλεία

Go εργαλεία

Ευτυχώς, το Go έρχεται με πολλά χρήσιμα εργαλεία, για να χτίσετε, να ελέγξετε και να ελέγξετε τον κωδικό σας. Στην πραγματικότητα, είναι όλα εκεί. Θα προσθέσουμε επιπλέον εργαλεία για να τα κολλήσουμε μαζί. Αλλά πριν πάμε εκεί, πρέπει να τους πάρουμε ένα προς ένα, και να δούμε τι κάνουν.

Λίστα πακέτων

Το πρόγραμμα Go σας είναι μια συλλογή πακέτων, όπως περιγράφεται στο επίσημο έγγραφο. Τα περισσότερα από τα παρακάτω εργαλεία θα τροφοδοτηθούν με αυτά τα πακέτα και έτσι η πρώτη εντολή που χρειαζόμαστε είναι ένας τρόπος για να απαριθμήσουμε τα πακέτα. Ας ελπίσουμε ότι, πηγαίνετε καλύπτει την πλάτη μας με την υποδιαίρεση της λίστας (διαβάστε το λεπτό εγχειρίδιο και αυτή την εξαιρετική θέση από τον Dave Cheney):

$ go list / ...

Σημειώστε ότι θέλουμε να αποφύγουμε την εφαρμογή των εργαλείων μας σε εξωτερικούς πόρους και να την περιορίσουμε στον κώδικα μας. Επομένως, πρέπει να απαλλαγούμε από τους καταλόγους πωλητών:

$ go list. / ... | grep -v / προμηθευτής /

Στουπί

Αυτό είναι το πρώτο εργαλείο που χρησιμοποιούμε για τον κώδικα: το linter. Ο ρόλος του είναι να διασφαλίσει ότι ο κώδικας σέβεται το στυλ κώδικα. Αυτό μπορεί να μοιάζει με ένα προαιρετικό εργαλείο, ή τουλάχιστον ένα "ωραίο-να-έχει", αλλά πραγματικά βοηθά να διατηρηθεί συνεπής στυλ πάνω από το έργο σας.

Αυτό το linter δεν είναι μέρος του go per se, οπότε πρέπει να το αρπάξετε και να το εγκαταστήσετε με το χέρι (δείτε το επίσημο έγγραφο).

Η χρήση είναι αρκετά απλή: το τρέχετε μόνο στα πακέτα του κώδικα (μπορείτε επίσης να δείξετε τα αρχεία .go):

$ golint -set_exit_status $ (μεταβείτε στη λίστα. / ... | grep -v / προμηθευτής /)

Σημειώστε την επιλογή -set_exit_status. Από προεπιλογή, το golint εκτυπώνει μόνο τα θέματα στυλ και επιστρέφει (με 0 επιστρεφόμενο κωδικό), οπότε ο CI δεν θεωρεί ποτέ ότι κάτι πήγε στραβά. Εάν καθορίσετε το -set_exit_status, ο κώδικας επιστροφής από το golint θα είναι διαφορετικός από το 0 εάν απαντηθεί κάποιο ζήτημα στυλ.

Δοκιμή μονάδας

Αυτές είναι οι πιο συνηθισμένες δοκιμές που μπορείτε να εκτελέσετε στον κώδικα σας. Για κάθε αρχείο .go, πρέπει να έχουμε ένα συσχετισμένο αρχείο _test.go που περιέχει τις δοκιμές μονάδας. Μπορείτε να εκτελέσετε τις δοκιμές για όλα τα πακέτα με την ακόλουθη εντολή:

$ go test -short $ (μεταβείτε στη λίστα. / ... | grep -v / vendor /)

Ο αγώνας δεδομένων

Αυτό είναι συνήθως ένα δύσκολο θέμα για κάλυψη, αλλά το εργαλείο go έχει από προεπιλογή (αλλά διατίθεται μόνο στα linux / amd64, freebsd / amd64, darwin / amd64 και windows / amd64). Για περισσότερες πληροφορίες σχετικά με τον αγώνα δεδομένων, δείτε αυτό το άρθρο. Εν τω μεταξύ, μπορείτε να το εκτελέσετε:

$ go test -race-σφάλμα $ (πηγαίνετε στη λίστα. / ... | grep -v / προμηθευτής /)

Απολυμαντικό μνήμης

Το Clang έχει έναν ωραίο ανιχνευτή για απροετοίμαστες αναφορές που ονομάζεται MemorySanitizer. Το εργαλείο δοκιμής go είναι αρκετά ευγενικό για να αλληλεπιδράσει με αυτό το module Clang (μόλις είστε στο linux / amd64 host και χρησιμοποιώντας μια πρόσφατη έκδοση Clang / LLVM (> = 3.8.0).) Αυτή η εντολή είναι πώς να την εκτελέσετε:

$ go test -msan -short $ (μεταβείτε στη λίστα. / ... | grep -v / vendor /)

Κάλυψη κώδικα

Αυτό είναι επίσης ένα πρέπει να πρέπει να αξιολογήσει την υγεία του κώδικα σας, και να δούμε τι το μέρος του κώδικα είναι υπό δοκιμές μονάδας και ποιο μέρος δεν είναι. Ο Rob Pike έγραψε μια πλήρη θέση σχετικά με αυτό το θέμα.

Για να υπολογίσουμε την αναλογία κάλυψης κώδικα, πρέπει να εκτελέσουμε το ακόλουθο σενάριο:

$ PKG_LIST = $ (πατήστε στη λίστα. / ... | grep -v / vendor /)
$ για το πακέτο σε $ {PKG_LIST}. κάνω
    go δοκιμή -covermode = count -coverprofile "κάλυψη / $ {package ## * /}." "πακέτο" ";
Έγινε
$ ουρά -q -n +2 κάλυψη / *. cov >> cover / coverage.cov
$ go κάλυμμα εργαλείου -func = cover / coverage.cov

Αν θέλουμε να λάβουμε την αναφορά κάλυψης σε μορφή HTML, πρέπει να προσθέσουμε την ακόλουθη εντολή:

$ go κάλυμμα εργαλείου -html = cover / coverage.cov -o coverage.html

Χτίζω

Τελευταίο, αλλά αν μη τι άλλο, μόλις ο κώδικας έχει δοκιμαστεί πλήρως, ίσως να θέλαμε να το συντάξουμε για να κάνουμε sur μπορούμε να οικοδομήσουμε ένα δυαδικό έργο.

$ go build -i -v gitlab.com/pantomath-io/demo-tools

Makefile

ετικέτα git: init-makefile

Φωτογραφία από τον Matt Artz στο Unsplash

Τώρα έχουμε όλα τα εργαλεία που μπορούμε να χρησιμοποιήσουμε στο πλαίσιο της συνεχιζόμενης ενσωμάτωσης, μπορούμε να τα τυλίξουμε όλα σε ένα Makefile και να έχουμε έναν συνεπή τρόπο να τα καλέσουμε.

Ο σκοπός αυτού του εγγράφου δεν είναι να παρουσιάσει μάρκα, αλλά μπορείτε να ανατρέξετε στην επίσημη τεκμηρίωση για να μάθετε περισσότερα σχετικά με αυτό.

PROJECT_NAME: = "demo-εργαλεία"
PKG: = "gitlab.com/pantomath-io/$(PROJECT_NAME)"
PKG_LIST: = $ (λίστα κελύφους $ {PKG} / ... | grep -v / πωλητής /)
GO_FILES: = $ (εντοπισμός κελύφους - όνομα '* .go' | grep -v / προμηθευτής / | grep -v _test.go)
.PHONE: όλα τα κτίρια κατασκευής καθαρή κάλυψη κάλυψης coverhtml χνούδι
όλα: κατασκευή
χνούδι: ## Lint τα αρχεία
 @golint -set_exit_status $ {PKG_LIST}
δοκιμή: ## Εκτελέστε δοκιμαστικές μονάδες
 @go test-σμίκρυνση $ {PKG_LIST}
race: dep ## Εκτελέστε τον ανιχνευτή αγώνα δεδομένων
 @go test -race-σμίκρυνση $ {PKG_LIST}
msan: dep ## Εκτελέστε απολυμαντικό μνήμης
 @go δοκιμή -συνάρτηση-μικρότερη $ {PKG_LIST}
κάλυψη: ## Δημιουργία συνολικής έκθεσης κάλυψης κώδικα
 ./tools/coverage.sh;
coverhtml: ## Δημιουργία αναφοράς παγκόσμιας κάλυψης κώδικα σε HTML
 ./tools/coverage.sh html;
dep: ## Λάβετε τις εξαρτήσεις
 @go get -v -d. / ...
build: dep ## Δημιουργία του δυαδικού αρχείου
 @go build -i -v $ (PKG)
clean: ## Αφαιρέστε την προηγούμενη κατασκευή
 @rm -f $ (PROJECT_NAME)
help: ## Εμφανίστε αυτήν την οθόνη βοήθειας
 @grep -h -E '^ [a-zA-Z _-] +:. *? ##. * $$' $ (MAKEFILE_LIST) | awk 'BEGIN {FS = ":. *? ##"}; {printm "\ 033 [36m% -30s \ 033 [0m% s \ n", $$ 1, $$ 2}

Τι έχουμε τώρα; Ένας στόχος για κάθε εργαλείο που παρουσιάστηκε προηγουμένως και 3 ακόμη στόχοι για:

  • εγκατάσταση εξαρτήσεων (dep);
  • διαχείριση του έργου (καθαρό) ·
  • κάποια ωραία και λαμπερή βοήθεια (βοήθεια).

Σημειώστε ότι έπρεπε επίσης να δημιουργήσουμε μια δέσμη ενεργειών για την εργασία κάλυψης κώδικα. Αυτό οφείλεται στο γεγονός ότι η εφαρμογή βρόχων σε αρχεία σε ένα Makefile είναι ένας πόνος. Έτσι, η εργασία γίνεται σε ένα script bash και το Makefile ενεργοποιεί μόνο αυτό το σενάριο.

Μπορείτε να δοκιμάσετε το Makefile με τις ακόλουθες εντολές:

Βοήθεια $
$ κάνουν χνούδι
$ κάνει κάλυψη

Συνεχής ενσωμάτωση

ετικέτα git: init-ci

Φωτογραφία από τον Max Panamá στο Unsplash

Τώρα τα εργαλεία είναι στη θέση τους και μπορούμε να εκτελέσουμε διάφορες δοκιμές στον κώδικα μας, θα θέλαμε να τις αυτοματοποιήσουμε στο αποθετήριο σας. Ευτυχώς, το GitLab προσφέρει αγωγούς CI μόνο για αυτό. Και η ρύθμιση για αυτό είναι αρκετά απλή: το μόνο που δημιουργείτε είναι ένα αρχείο .gitlab-ci.yml στη ρίζα του αποθετηρίου.

Η πλήρης τεκμηρίωση αυτού του αρχείου Yaml παρουσιάζει όλες τις επιλογές, αλλά μπορείτε να ξεκινήσετε με αυτό το .gitlab-ci.yml:

εικόνα: golang: 1.9
κρύπτη:
  μονοπάτια:
    - / apt-cache
    - /go/src/github.com
    - /go/src/golang.org
    - /go/src/google.golang.org
    - /go/src/gopkg.in
στάδια:
  - δοκιμή
  - χτίζω
before_script:
  - mkdir -p /go/src/gitlab.com/pantomath-io/ go / src / _ / builds
  - cp -r $ CI_PROJECT_DIR /go/src/gitlab.com/pantomath-io/pantomath
  - ln -s /go/src/gitlab.com/pantomath-io/ go / src / _ / builds / pantomath-io
  - κάνε αναπλήρωση
units_tests:
  στάδιο: δοκιμή
  γραφή:
    - κάντε δοκιμή
race_detector:
  στάδιο: δοκιμή
  γραφή:
    - να κάνεις αγώνα
memory_sanitizer:
  στάδιο: δοκιμή
  γραφή:
    - Κάνε msan
code_coverage:
  στάδιο: δοκιμή
  γραφή:
    - Κάντε κάλυψη
code_coverage_report:
  στάδιο: δοκιμή
  γραφή:
    - κάνουν coverhtml
  μόνο:
  - πλοίαρχος
lint_code:
  στάδιο: δοκιμή
  γραφή:
    - κάνετε χνούδι
χτίζω:
  στάδιο: κατασκευή
  γραφή:
    - φτιαχνω, κανω

Εάν κατακερματιστείτε το αρχείο, ακολουθούν ορισμένες εξηγήσεις σχετικά με το περιεχόμενό του:

  • Το πρώτο είναι να επιλέξετε ποια εικόνα Docker θα χρησιμοποιηθεί για να εκτελέσετε τον CI. Προχωρήστε στο Hub του Docker για να επιλέξετε τη σωστή εικόνα για το έργο σας.
  • Στη συνέχεια, καθορίζετε ορισμένους φακέλους αυτής της εικόνας που θα αποθηκευτούν στην κρυφή μνήμη. Ο στόχος εδώ είναι να αποφευχθεί η λήψη του ίδιου περιεχομένου αρκετές φορές. Μόλις ολοκληρωθεί η εργασία, οι καταχωρημένες διαδρομές θα αρχειοθετηθούν και η επόμενη εργασία θα χρησιμοποιήσει το ίδιο αρχείο.
  • Ορίζετε τα διάφορα στάδια που θα ομαδοποιήσουν τις εργασίες σας. Στην περίπτωσή μας, έχουμε δύο στάδια (προς επεξεργασία με αυτή τη σειρά): δοκιμή και κατασκευή. Θα μπορούσαμε να έχουμε άλλα στάδια, όπως την ανάπτυξη.
  • Η ενότητα previous_script ορίζει τις εντολές που εκτελούνται στο δοχείο Docker ακριβώς πριν γίνει πραγματικά η εργασία. Στο πλαίσιο μας, οι εντολές απλά αντιγράψτε ή συνδέστε το αποθετήριο που αναπτύσσεται στο $ GOPATH και εγκαταστήστε εξαρτήσεις.
  • Στη συνέχεια, έρχονται οι πραγματικές εργασίες, χρησιμοποιώντας τους στόχους Makefile. Σημειώστε την ειδική περίπτωση του code_coverage_report, όπου η εκτέλεση είναι περιορισμένη στο κύριο υποκατάστημα (για παράδειγμα, δεν θέλουμε να ενημερώσουμε την αναφορά κάλυψης κώδικα από κλάδους χαρακτηριστικών).

Καθώς δεσμευόμαστε / πιέζουμε το αρχείο .gitlab-ci.yml στο αποθετήριο, ενεργοποιείται αυτόματα το CI. Και ο αγωγός αποτυγχάνει. Πώς κι έτσι?

Η εργασία lint_code αποτυγχάνει επειδή δεν μπορεί να βρει το δυαδικό όνομα golint:

$ κάνουν χνούδι
κάνουν: Golint: Η εντολή δεν βρέθηκε
Makefile: 11: συνταγή για στόχο "χνούδι" απέτυχε
κάντε: *** [χνούδι] Σφάλμα 127

Επομένως, ενημερώστε το Makefile σας για να εγκαταστήσετε το golint ως μέρος του target target.

Η εργασία memory_sanitizer αποτυγχάνει επειδή η gcc διαμαρτύρεται:

$ make msan
# runtime / cgo
gcc: σφάλμα: μη αναγνωρισμένο όρισμα στο -fsanitize = επιλογή: 'μνήμη'
Makefile: 20: η συνταγή για το target 'msan' απέτυχε
κάνει: *** [msan] Σφάλμα 2

Αλλά θυμηθείτε ότι πρέπει να χρησιμοποιήσετε το Clang / LLVM> = 3.8.0 για να απολαύσετε την εντολή -mane στην εντολή go test.

Έχουμε 2 επιλογές εδώ:

  • είτε ρυθμίζουμε τον Clang στη δουλειά (χρησιμοποιώντας το προηγούμενο_script).
  • ή χρησιμοποιούμε μια εικόνα Docker με Clang εγκατεστημένη από προεπιλογή.

Η πρώτη επιλογή είναι ωραία, αλλά αυτό σημαίνει ότι έχει γίνει αυτή η ρύθμιση για κάθε εργασία. Αυτό θα είναι τόσο μεγάλο, θα πρέπει να το κάνουμε μια για πάντα. Έτσι προτιμούμε τη δεύτερη επιλογή, η οποία είναι ένας καλός τρόπος να παίξετε με το GitLab Registry.

git tag: use-own-docker

Πρέπει να δημιουργήσουμε ένα Dockerfile για το δοχείο (ως συνήθως: διαβάστε την επίσημη τεκμηρίωση για περισσότερες επιλογές γι 'αυτό):

# Base image: https://hub.docker.com/_/golang/
Από golang: 1.9
ΣΥΝΤΗΛΗ Julien Andrieux 
# Εγκαταστήστε το γκολφ
ENV GOPATH / go
ENV PATH $ {GOPATH} / bin: $ PATH
RUN go get -u github.com/golang/lint/golint
# Προσθήκη κλειδιού apt για αποθήκη LLVM
RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
# Προσθήκη LLVM apt repository
RUN echo "deb http://apt.llvm.org/stretch/ llvm-toolchain-stretch-5.0 κύρια" | tee -a /etc/apt/sources.list
# Εγκαταστήστε clang από το LLVM repository
RUN apt-get ενημέρωση && apt-get install -y --no-install-recommends \
    clang-5.0 \
    && apt-get clean \
    && rm -rf / var / lib / apt / λίστες / * / tmp / * / var / tmp / *
# Καταχωρίστε τον Clang ως προεπιλεγμένο CC
ENV set_clang /etc/profile.d/set-clang-cc.sh
RUN echo "εξαγωγή CC = clang-5.0" | tee -a $ {set_clang} && chmod α + x $ {set_clang}

Το δοχείο που είναι κατασκευασμένο από αυτό το αρχείο Dockerfile θα βασίζεται σε εικόνα golang: 1.9 (η οποία αναφέρεται στο αρχείο .gitlab-ci.yml).

Ενώ βρισκόμαστε σε αυτό, εγκαθιστούμε το γκολίν στο δοχείο, έτσι το διαθέτουμε. Στη συνέχεια, ακολουθούμε τον επίσημο τρόπο εγκατάστασης του Clang 5.0 από το LLVM repository.

Τώρα έχουμε το Dockerfile στη θέση του, πρέπει να κατασκευάσουμε την εικόνα του δοχείου και να το διαθέσουμε για το GitLab:

$ docker login registry.gitlab.com
$ docker build -t registry.gitlab.com/pantomath-io/demo-tools.
$ docker push register.gitlab.com/pantomath-io/demo-tools

Η πρώτη εντολή σας συνδέει με το Μητρώο GitLab. Στη συνέχεια, δημιουργείτε την εικόνα δοχείου που περιγράφεται στο αρχείο Docker. Και τελικά, το πιέζετε στο Μητρώο GitLab.

Ρίξτε μια ματιά στο μητρώο για την αποθήκη σας, θα δείτε την εικόνα σας, έτοιμη να χρησιμοποιηθεί. Και για να έχετε τον CI χρησιμοποιώντας την εικόνα σας, πρέπει απλώς να ενημερώσετε το αρχείο .gitlab-ci.yml:

εικόνα: golang: 1.9

γίνεται

εικόνα: registry.gitlab.com/pantomath-io/demo-tools:latest

Μια τελευταία λεπτομέρεια: πρέπει να πείτε στο CI να χρησιμοποιήσει τον κατάλληλο μεταγλωττιστή (δηλ. Την μεταβλητή περιβάλλοντος CC), έτσι προσθέτουμε την αρχική μεταβλητή στο αρχείο .gitlab-ci.yml:

εξαγωγή CC = clang-5.0

Μόλις γίνει η τροποποίηση, η επόμενη δέσμευση θα ενεργοποιήσει τον αγωγό, ο οποίος λειτουργεί τώρα:

https://gitlab.com/pantomath-io/demo-tools/pipelines/13497136

Σήματα

ετικέτα git: init-κονκάρδες

Φωτογραφία από τον Jakob Owens στο Unsplash

Τώρα τα εργαλεία είναι στη θέση τους, κάθε commit θα ξεκινήσει μια δοκιμαστική σουίτα και ίσως θέλετε να την δείξετε και αυτό είναι νόμιμο :) Ο καλύτερος τρόπος να το κάνετε είναι να χρησιμοποιήσετε κονκάρδες και το καλύτερο μέρος για αυτό είναι το αρχείο README.

Επεξεργαστείτε το και προσθέστε τα ακόλουθα 4 κονκάρδες:

  • Κατάσταση κατασκευής: η κατάσταση του τελευταίου αγωγού στον κύριο κλάδο:
[! [Κατάσταση κατασκευής] (https://gitlab.com/pantomath-io/demo-tools/badges/master/build.svg)] (https://gitlab.com/pantomath-io/demo-tools/commits /κύριος)
  • Έκθεση κάλυψης: το ποσοστό του κωδικού που καλύπτεται από τις δοκιμές
[! [Έκθεση κάλυψης] (https://gitlab.com/pantomath-io/demo-tools/badges/master/coverage.svg)] (https://gitlab.com/pantomath-io/demo-tools/commits /κύριος)
  • Μεταβείτε στην κάρτα αναφοράς:
[! [Go Report Card] (https://goreportcard.com/badge/gitlab.com/pantomath-io/demo-tools)] (https://goreportcard.com/report/gitlab.com/pantomath-io/ demo-εργαλεία)
  • Αδεια:
[! [MIT License] (https://img.shields.io/badge/License-MIT-brightgreen.svg)] (https://img.shields.io/badge/License-MIT-brightgreen.svg)

Η έκθεση κάλυψης χρειάζεται μια ειδική διαμόρφωση. Πρέπει να πείτε στο GitLab πώς να αποκτήσετε αυτές τις πληροφορίες, θεωρώντας ότι υπάρχει μια δουλειά στο CI που το εμφανίζει όταν τρέχει.
Υπάρχει μια διαμόρφωση για την παροχή του GitLab με regexp, που χρησιμοποιείται σε κάθε εργασία. Αν το regexp ταιριάζει, το GitLab θεωρεί ότι ο αγώνας είναι το αποτέλεσμα της κάλυψης κώδικα.

Έτσι, κατευθυνθείτε στις Ρυθμίσεις> CI / CD στην αποθήκη σας, μετακινηθείτε προς τα κάτω στη ρύθμιση Ανάλυση κάλυψης δοκιμής στην ενότητα Γενικές ρυθμίσεις ρυθμίσεων αγωγών και χρησιμοποιήστε το ακόλουθο regexp:

Σύνολο: \ s + \ (δηλώσεις \) \ s + (\ d +. \ d + \%)

Είσαι έτοιμος! Επισκεφθείτε την επισκόπηση του αποθετηρίου σας και ανατρέξτε στο README:

συμπέρασμα

Τι έπεται? Πιθανώς περισσότερες δοκιμές σε εσάς CI. Μπορείτε επίσης να δείτε το CD (συνεχής ανάπτυξη) για να αυτοματοποιήσετε την ανάπτυξη των build σας. Η τεκμηρίωση μπορεί να γίνει χρησιμοποιώντας GoDoc. Σημειώστε ότι δημιουργείτε μια αναφορά κάλυψης με το code_coverage_report, αλλά μην τη χρησιμοποιείτε στο CI. Μπορείτε να κάνετε τη δουλειά να αντιγράψετε το αρχείο HTML σε ένα διακομιστή ιστού, χρησιμοποιώντας scp (δείτε αυτή την τεκμηρίωση σχετικά με τον τρόπο χρήσης των κλειδιών SSH).

Πολλές ευχαριστίες στον Charles Francoise, ο οποίος συνυπέγραψε αυτό το έγγραφο και το https://gitlab.com/pantomath-io/demo-tools.

Αυτή τη στιγμή δουλεύουμε στο Pantomath. Το Pantomath είναι μια σύγχρονη λύση παρακολούθησης ανοικτού κώδικα, κατασκευασμένη για επιδόσεις, που γεφυρώνει τα κενά σε όλα τα επίπεδα της εταιρείας σας. Η ευημερία της υποδομής σας είναι επιχείρηση όλων. Συνεχίστε με το έργο