Πώς να ρυθμίσετε αγωγούς GitLab Continuous Integration (CI) σε Ubuntu 20.04

Κάθε προγραμματιστής κατανοεί πόσο κρίσιμος είναι ο έλεγχος εκδόσεων για τον κύκλο ζωής ανάπτυξης λογισμικού. Επιτρέπει σε πολλά άτομα να εργάζονται ταυτόχρονα σε ένα μόνο έργο, με κάθε άτομο να διατηρεί το δικό του αντίγραφο του κώδικα και να επιλέγει πότε θα τον μοιραστεί με την υπόλοιπη ομάδα. Για να το επιτύχουν αυτό, οι προγραμματιστές χρησιμοποιούν Git αποθετήρια για να βοηθήσουν με τον έλεγχο εκδόσεων. GitLab είναι ένα web-based Git αποθετήριο που είναι κάτι περισσότερο από ένα εργαλείο ελέγχου εκδόσεων. Παρέχει επιπλέον εργαλεία DevOps, παρακολούθηση ζητημάτων (issue-tracking), συνεχή ενσωμάτωση (continuous integration) και ανάπτυξη (deployment).

Το GitLab προσφέρει τρεις επιλογές από τις οποίες μπορείτε να επιλέξετε: GitLab Community Edition (CE), GitLab Enterprise Edition (EE) και GitLab SaaS. GitLab CE και GitLab EE είναι αυτοδιαχειριζόμενες (self-managed) λύσεις. Αυτό σημαίνει ότι μπορείτε να κατεβάσετε, να εγκαταστήσετε και να διαχειριστείτε το GitLab instance μόνοι σας. Το GitLab SaaS φιλοξενείται από την GitLab Inc. Έτσι, δεν χρειάζεται να ανησυχείτε για την εγκατάσταση οτιδήποτε προκειμένου να το χρησιμοποιήσετε. Χρειάζεται μόνο να δημιουργήσετε έναν λογαριασμό GitLab και να ξεκινήσετε.

Σε αυτόν τον οδηγό, θα σας δείξουμε πώς να ρυθμίσετε αγωγούς Συνεχούς Ενσωμάτωσης (Continuous Integration pipelines) με το GitLab CI για να παρακολουθείτε τα αποθετήριά σας για αλλαγές και να εκτελείτε αυτοματοποιημένες δοκιμές για την επικύρωση νέου κώδικα. Θα ξεκινήσουμε ρυθμίζοντας ένα Git αποθετήριο για τη φιλοξενία του κώδικα. Στη συνέχεια, θα διαμορφώσουμε μια διαδικασία CI για την παρακολούθηση των commits στο αποθετήριο και θα εκκινήσουμε έναν CI runner για την εκτέλεση των δοκιμών σε ένα απομονωμένο Docker container.

Προαπαιτούμενα

Για να ξεκινήσετε, θα χρειαστείτε έναν διακομιστή που εκτελεί το λογισμικό ελέγχου εκδόσεων GitLab. Τόσο το self-managed GitLab όσο και το SaaS μπορούν να εκτελέσουν αυτοματοποιημένες δοκιμές. Ωστόσο, υπάρχουν κάποιοι περιορισμοί όσον αφορά τα λεπτά και τους πόρους που διατίθενται για τις δοκιμές σας στις δωρεάν επιλογές SaaS. Έχετε μεγαλύτερη ελευθερία εάν χρησιμοποιείτε τις self-managed επιλογές, επειδή μπορείτε να διαθέσετε όσους πόρους επιθυμείτε στο δικό σας GitLab instance. Ακολουθήστε τον οδηγό μας για τη φιλοξενία των δικών σας Git αποθετηρίων με το GitLab για να μάθετε πώς να ρυθμίσετε το δικό σας GitLab instance.

Θα χρειαστείτε τουλάχιστον έναν διακομιστή για να τον χρησιμοποιήσετε ως GitLab CI runner. Ωστόσο, αν θέλετε, μπορείτε να έχετε και περισσότερους διακομιστές. Εάν έχετε ρυθμίσει ένα self-managed GitLab instance, μπορείτε να χρησιμοποιήσετε τον ίδιο διακομιστή, αλλά προτιμούμε να ορίσουμε έναν διαφορετικό διακομιστή για τον CI runner. Αυτός ο οδηγός για το Πώς να ρυθμίσετε τον Ubuntu διακομιστή σας είναι μια καλή αρχή.

Θα χρειαστεί να έχετε εγκατεστημένο το Docker στους διακομιστές GitLab CI runner για να απομονώσετε τα περιβάλλοντα δοκιμών σε Docker containers. Έχουμε έναν οδηγό για το Πώς να εγκαταστήσετε και να λειτουργήσετε το Docker στο Ubuntu που μπορεί να σας βοηθήσει να ολοκληρώσετε αυτήν την απαίτηση.

Τώρα που έχουμε όλα όσα χρειαζόμαστε, ας ξεκινήσουμε!

Βήμα 1: Δημιουργία ενός Project σε ένα GitLab Instance

Θα ξεκινήσουμε δημιουργώντας ένα αποθετήριο έργου στο GitLab. Θα βασίσουμε αυτόν τον οδηγό σε μια εφαρμογή Node.js. Επειδή δεν θέλουμε να δημιουργήσουμε τα αρχεία του έργου από το μηδέν, το GitLab προσφέρει ένα εργαλείο για την εισαγωγή έργων από άλλα αποθετήρια ελέγχου εκδόσεων, το οποίο και θα χρησιμοποιήσουμε. Η εφαρμογή που εισάγουμε είναι μια απλή εφαρμογή “hello world” κατασκευασμένη με Express.js – ένα μινιμαλιστικό web framework για εφαρμογές Node.js. Θα υλοποιήσουμε τις δοκιμές χρησιμοποιώντας Mocha και Chai – αυτά είναι JavaScript frameworks που χρησιμοποιούνται για unit testing. Το Mocha επιτρέπει ασύγχρονες δοκιμές, αναφορές κάλυψης δοκιμών (test coverage reports) και μπορεί να συνδυαστεί με άλλες βιβλιοθήκες ισχυρισμών (assertion libraries). Το Chai είναι μια βιβλιοθήκη ισχυρισμών. Μπορεί να συνδυαστεί με οποιοδήποτε test framework, και στη δική μας περίπτωση, θα συνδυάσουμε το Mocha με το Chai.

Τώρα που γνωρίζετε τα βασικά του έργου μας, συνδεθείτε στο δικό σας GitLab instance (είτε self-managed είτε SaaS), κάντε κλικ στο εικονίδιο ‘συν’ στην επάνω γραμμή πλοήγησης και επιλέξτε ‘New project’. Προαιρετικά, εάν μετακινηθείτε στο επάνω μέρος της αρχικής σελίδας του λογαριασμού σας, μπορείτε να κάνετε κλικ στο κουμπί ‘New project’:

Στη σελίδα του νέου έργου, κάντε κλικ στην καρτέλα Import project :

Στη συνέχεια, στην ανοιχτή σελίδα, κάντε κλικ στο κουμπί Repo by URL :

Αν και υπάρχει η επιλογή εισαγωγής από το GitHub, δεν πρόκειται να τη χρησιμοποιήσουμε καθώς απαιτεί ένα Personal access token. Δεν χρειάζεται να ρυθμίσουμε Personal access tokens αφού εργαζόμαστε με ένα δημόσιο αποθετήριο, και η εισαγωγή μόνο με το URL είναι απλή.

Μετά από αυτό, αντιγράψτε την ακόλουθη διεύθυνση URL και επικολλήστε τη στο πεδίο Git Repository URL:

Θα πρέπει να μοιάζει κάπως έτσι:

Αφήστε το αποθετήριο ως Private και κάντε κλικ στο κουμπί Create project όταν τελειώσετε. Περιμένετε μερικά δευτερόλεπτα για να εισαχθεί το έργο από το GitHub και θα εμφανιστεί ανάμεσα στα αποθετήριά σας στο GitLab. Το GitLab εισάγει το έργο με τις ίδιες λεπτομέρειες όπως το έργο του αποθετηρίου GitHub.

Βήμα 2: Ανάλυση του αρχείου .gitlab-ci.yml

Το GitLab CI σαρώνει κάθε αποθετήριο στο GitLab για ένα αρχείο με το όνομα .gitlab-ci.yml για να γνωρίζει πώς πρέπει να εκτελέσει τις αυτοματοποιημένες δοκιμές. Στο αποθετήριο που μόλις εισαγάγαμε, μπορείτε να δείτε ένα αρχείο .gitlab-ci.yml ανάμεσα στα αρχεία του έργου. Μπορείτε να βρείτε περισσότερες πληροφορίες σχετικά με το GitLab CI yml στην επίσημη τεκμηρίωση Keyword reference for the .gitlab-ci.yml file.

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

Παρατηρήστε την εσοχή των γραμμών. Το αρχείο ακολουθεί μια αυστηρή GitLab CI YAML σύνταξη διαμόρφωσης για να ορίσει τις διάφορες ενέργειες που πρέπει να ληφθούν, με καθορισμένη σειρά υπό ορισμένες συνθήκες. Για να διασφαλίσετε ότι τα αρχεία διαμόρφωσής σας είναι σωστά, το GitLab παρέχει ένα βοηθητικό πρόγραμμα δοκιμής για επικύρωση. Μέσα στο GitLab instance σας, στο αποθετήριο του έργου σας, μπορείτε να επισκεφτείτε τη διεπαφή CI lint για να επικυρώσετε το .gitlab-ci.yml. Κάντε κλικ στο CI/CD στο αριστερό μενού πλοήγησης και κάντε κλικ στο κουμπί CI lint στη σελίδα που εμφανίζεται:

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

• Βασική εικόνα Docker

Η πρώτη γραμμή στο αρχείο διαμόρφωσης δηλώνει μια εικόνα Docker που πρέπει να χρησιμοποιηθεί για την εκτέλεση των δοκιμών. Εφόσον κατασκευάζουμε μια εφαρμογή Node.js, θα επιλέξουμε την πιο πρόσφατη εικόνα Node.js:

• Στάδια

Στη συνέχεια, ορίζουμε τα διάφορα στάδια από τα οποία θέλουμε να περάσουν οι δοκιμές συνεχούς ενοποίησης (continuous integration). Έχουμε μόνο δύο στάδια:

Κατά τον ορισμό των ονομάτων των σταδίων, ονόματα όπως build ή test επιλέγονται τυχαία – μπορείτε να επιλέξετε όποιο όνομα θέλετε. Ωστόσο, πρέπει να ταξινομήσετε σωστά τα στάδια επειδή αυτό καθορίζει τη ροή εκτέλεσης. Στη δική μας περίπτωση, οι εργασίες στο στάδιο build εκτελούνται πριν από τις εργασίες στο στάδιο test stage. Ο GitLab runner θα εκτελέσει τις εργασίες στο ίδιο στάδιο παράλληλα και θα περιμένει να ολοκληρωθούν όλες οι εργασίες προτού ξεκινήσει την εκτέλεση εργασιών στο επόμενο στάδιο.

• Cache

Ένας ορισμός cache περιλαμβάνεται για να καθορίσει τα αρχεία και τους καταλόγους που θα αποθηκευτούν στην προσωρινή μνήμη (cached) ή θα αποθηκευτούν για μεταγενέστερη χρήση μεταξύ των εκτελέσεων των εργασιών:

Ο ορισμός της προσωρινής αποθήκευσης (caching) βοηθά στην ελαχιστοποίηση του χρόνου που απαιτείται για την εκτέλεση εργασιών που βασίζονται σε πόρους που είναι απίθανο να αλλάξουν μεταξύ των εκτελέσεων. Καθορίζουμε τον κατάλογο node_modules για προσωρινή αποθήκευση. Αυτός είναι ο κατάλογος στον οποίο το npm εγκαθιστά τις εξαρτήσεις για το έργο.

• Εργασίες

Έχουμε δύο εργασίες στη διαμόρφωση:

• install_dependencies

Όταν ονομάζετε εργασίες, είστε ελεύθεροι να επιλέξετε οποιοδήποτε όνομα. Ωστόσο, συνιστάται να επιλέξετε ένα περιγραφικό όνομα, καθώς αυτά χρησιμοποιούνται στο περιβάλλον εργασίας (UI) του GitLab – αυτό μπορεί να είναι χρήσιμο κατά τον εντοπισμό σφαλμάτων. Θα βρείτε τις περισσότερες διαμορφώσεις στον ιστό να συνδυάζουν το npm install με τις εντολές στο στάδιο δοκιμής (test stage). Τις διαχωρίσαμε μόνο για να βοηθήσουμε στην επίδειξη του πώς αλληλεπιδρούν οι εργασίες, καθώς πρόκειται για ένα αρκετά μικρό έργο. Το stage οδηγία επισημαίνει αυτήν την εργασία ως build – εκτελείται στο build stage.

Η script οδηγία καθορίζει τις εντολές που θα εκτελεστούν κατά την εκτέλεση αυτής της εργασίας. Μπορείτε να καθορίσετε πολλαπλές εντολές προσθέτοντας γραμμές μέσα στο script block. Φυσικά, πρέπει να είστε προσεκτικοί με τη σωστή εσοχή και να έχετε κατά νου τη σειρά με την οποία πρέπει να εκτελεστούν τα σενάρια.

Η artifacts οδηγία καθορίζει αρχεία ή διαδρομές καταλόγων που θα αποθηκευτούν και θα κοινοποιηθούν μεταξύ των σταδίων. Ξανά, μια υπενθύμιση ότι η σωστή σειρά των σταδίων είναι κρίσιμη για να διασφαλιστεί ότι άλλα αρχεία θα έχουν ό,τι χρειάζονται για να εκτελεστούν. Η npm install εντολή θα εγκαταστήσει τις εξαρτήσεις στον κατάλογο node_modules . Δηλώνοντάς το στα artifacts, το καθιστούμε διαθέσιμο σε εργασίες που εκτελούνται σε επόμενα στάδια. Τα αρχεία είναι επίσης διαθέσιμα στο UI του GitLab εάν θέλετε να τα κατεβάσετε.

• test_with_mocha

Αυτή η εργασία εκτελείται στο test stage. Εφόσον αυτή η εργασία εκτελείται μετά την εκτέλεση της εργασίας στο build stage, τα artifacts που δηλώθηκαν στο build stage (τα οποία είναι οι εξαρτήσεις για την εφαρμογή μας) θα είναι διαθέσιμα στο test stage. Το script block καθορίζει τις npm εντολές για την εκτέλεση των δοκιμών μας. Αρχικά ξεκινάμε την εφαρμογή μας και στη συνέχεια εκτελούμε τις δοκιμές στην εφαρμογή. Η εκτέλεση αυτών των εντολών ενεργοποιεί τις εντολές που καθορίζονται στην ενότητα script block του package.json :
Με αυτό, θα πρέπει να έχετε μια βασική κατανόηση του αρχείου .gitlab-ci.yml. Λέμε βασική επειδή αυτή είναι μόνο μια στατική εφαρμογή hello world. Στη συνέχεια, ας δούμε πώς μπορούμε να ενεργοποιήσουμε μια νέα εκτέλεση CI.

Βήμα 3: Ενεργοποίηση μιας εκτέλεσης GitLab CI

Θα χαρείτε να μάθετε ότι μόλις το αποθετήριό σας αποκτήσει το αρχείο .gitlab-ci.yml, οποιαδήποτε νέα commits κάνετε push σε αυτό θα ενεργοποιήσουν μια νέα εκτέλεση Continuous Integration. Στην περίπτωση αυτοδιαχειριζόμενων παρουσιών GitLab, εάν δεν έχετε ρυθμίσει έναν GitLab runner, η εκτέλεση CI θα οριστεί σε «pending» (σε εκκρεμότητα).

Το GitLab SaaS παρέχει στους χρήστες ορισμένους shared runners που μπορούν να αναλάβουν τις εργασίες τους και να τις εκτελέσουν αυτόματα. Αυτό είναι εφικτό μόνο εάν οι shared runners είναι ελεύθεροι και δεν έχετε υπερβεί το όριό σας. Στο GitLab SaaS, μπορείτε να επιλέξετε εάν θέλετε το αποθετήριό σας να χρησιμοποιεί τους shared runners ή όχι, μεταβαίνοντας στη σελίδα του έργου σας Settings > CI / CD, όπως φαίνεται στο παρακάτω στιγμιότυπο οθόνης. Σε αυτήν τη σελίδα, θα βρείτε επίσης πληροφορίες σχετικά με τις οδηγίες εγκατάστασης του GitLab runner, στις οποίες θα εμβαθύνουμε στο επόμενο βήμα:

Τώρα, ας κάνουμε μια μικρή αλλαγή για να ενεργοποιήσουμε μια εκτέλεση CI. Πλοηγηθείτε πίσω στο αποθετήριο του έργου σας GitLab node_pipeline:

Κάντε κλικ στο αρχείο README.md που επισημαίνεται παραπάνω για να το δείτε:

Κάντε κλικ στο κουμπί ‘Edit’ για να ανοίξετε το αρχείο για επεξεργασία στο πρόγραμμα περιήγησης και προσθέστε λίγο κείμενο:

Αφού προσθέσετε κάποιο κείμενο, κυλήστε προς τα κάτω και κάντε κλικ στο κουμπί Commit changes για να αποθηκεύσετε τις αλλαγές. Μπορείτε να τροποποιήσετε το μήνυμα commit όπως επιθυμείτε. Θα εμφανιστεί ως τίτλος στο UI του GitLab όταν εκτελείται το pipeline. Το έχουμε αφήσει ως Update README.md καθώς είναι αρκετά περιγραφικό:

Μόλις υποβάλετε τις αλλαγές (commit), επιστρέψτε στην κεντρική σελίδα του έργου. Θα παρατηρήσετε ένα μικρό paused icon δίπλα στο πιο πρόσφατο commit. Εάν περάσετε το ποντίκι σας πάνω από το εικονίδιο, θα εμφανιστεί το μήνυμα: ‘Pipeline:pending’:

Αυτό σημαίνει ότι η εκτέλεση CI ενεργοποιήθηκε. Ωστόσο, οι δοκιμές δεν έχουν εκτελεστεί ακόμα. Στο μενού πλοήγησης στα αριστερά, κάντε κλικ στο CI/CD, και στη συνέχεια επιλέξτε Pipelines. Αυτό θα ανοίξει μια σελίδα που δείχνει περισσότερες λεπτομέρειες σχετικά με το pipeline. Μπορείτε να δείτε ότι το CI είναι σε εκκρεμότητα και έχει επισημανθεί ως κολλημένο (stuck):

Για να λάβετε περισσότερες λεπτομέρειες σχετικά με την εκτέλεση, κάντε κλικ στην κατάσταση pending. Θα δείτε την παρακάτω προβολή, η οποία εμφανίζει τα διάφορα στάδια της εκτέλεσης και τις επιμέρους εργασίες που συνδέονται με κάθε στάδιο:

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

Το μήνυμα υποδεικνύει ότι η εργασία έχει κολλήσει επειδή δεν έχετε ρυθμίσει κανέναν ενεργό runner που να μπορεί να εκτελέσει αυτήν την εργασία. Θα το κάνουμε αυτό στο επόμενο βήμα. Όταν κάνετε έναν runner διαθέσιμο, η εργασία θα αρχίσει να εκτελείται αυτόματα. Όταν μια εργασία εκτελείται, θα βλέπετε το αποτέλεσμα σε αυτήν τη διεπαφή καθώς και τα άλλα λήψιμα artifacts που δημιουργήθηκαν κατά την εκτέλεση της εργασίας.

Βήμα 4: Ρύθμιση μιας υπηρεσίας GitLab CI Runner

Ήρθε η ώρα να χρησιμοποιήσουμε τον δεύτερο διακομιστή που δηλώσαμε στην ενότητα Προαπαιτούμενα αυτού του οδηγού. Θα εγκαταστήσουμε και θα ρυθμίσουμε μια υπηρεσία GitLab runner σε αυτόν τον διακομιστή. Μπορείτε να αναπτύξετε την υπηρεσία για να εκτελέσετε πολλαπλά στιγμιότυπα runner για διαφορετικά έργα στο GitLab.

Έχετε την επιλογή να αναπτύξετε τον runner στον ίδιο διακομιστή που φιλοξενεί το self-managed στιγμιότυπο GitLab σας. Ωστόσο, για να διασφαλίσετε ότι ένα στιγμιότυπο δεν περιορίζεται από πόρους, είναι προτιμότερο να ρυθμίσετε ένα ξεχωριστό στιγμιότυπο CI runner. Όποια διαμόρφωση κι αν επιλέξετε, το Docker πρέπει να είναι εγκατεστημένο για την απομόνωση των περιβαλλόντων δοκιμών.

Η διαδικασία εγκατάστασης του GitLab CI runner είναι παρόμοια με εκείνη για την εγκατάσταση του self-managed GitLab στιγμιοτύπου. Ξεκινάμε κατεβάζοντας ένα σενάριο για να προσθέσουμε το επίσημο αποθετήριο GitLab στις πηγές apt χρησιμοποιώντας την ακόλουθη εντολή:

Δώστε τον κωδικό πρόσβασης root όταν σας ζητηθεί. Στη συνέχεια, μπορείτε τώρα να εκτελέσετε την εντολή για να εγκαταστήσετε τον πιο πρόσφατο GitLab CI runner:

Η παραπάνω εντολή εγκαθιστά και καταχωρεί μια υπηρεσία runner έτοιμη προς χρήση από τα έργα σας.

Βήμα 5: Απόκτηση διακριτικών εγγραφής και σύνδεση του GitLab Runner

Για να ρυθμίσετε έναν GitLab CI runner ώστε να αρχίσει να δέχεται εργασίες, χρειάζεστε ένα GitLab runner token. Είναι απαραίτητο για τον runner προκειμένου να πιστοποιηθεί στο στιγμιότυπο του διακομιστή GitLab σας. Υπάρχουν δύο τύποι tokens ανάλογα με τον τρόπο που θέλετε να χρησιμοποιήσετε τον runner: project-specific και shared runner.

Οι project-specific runners είναι κατάλληλοι εάν έχετε μοναδικές απαιτήσεις για τον runner. Για παράδειγμα, εάν έχετε ορισμούς ανάπτυξης στο αρχείο gitlab-ci.yml με μοναδικά tokens, τότε μπορεί να συνιστάται ένας συγκεκριμένος runner για τη σωστή πιστοποίηση στο περιβάλλον ανάπτυξης. Ένα άλλο στοιχείο που πρέπει να λάβετε υπόψη είναι εάν τα στάδια συνεχούς ενοποίησης έχουν διαδικασίες έντασης πόρων. Τότε, θα ήταν ιδανικό να επιλέξετε έναν project-specific runner. Σημειώστε ότι ένας project-specific runner δεν δέχεται εργασίες από άλλα έργα.

Οι shared runners είναι γενικής χρήσης και μπορούν να χρησιμοποιηθούν από πολλαπλά έργα. Το στιγμιότυπο GitLab SaaS που φιλοξενείται στο GitLab Inc διαθέτει ορισμένους shared runners που θα αναλάβουν αυτόματα τα pipelines σας, όπως εξηγείται στο Βήμα Τρία. Οι runners λαμβάνουν εργασίες από τις διαμορφώσεις σας με βάση έναν αλγόριθμο που λαμβάνει υπόψη τον αριθμό των εργασιών που εκτελούνται αυτήν τη στιγμή για κάθε έργο. Ένας shared runner είναι πιο ευέλικτος από έναν συγκεκριμένο runner. Μπορεί να διαμορφωθεί από τον λογαριασμό διαχειριστή του στιγμιοτύπου GitLab. Ας δούμε πώς μπορούμε να αποκτήσουμε τα tokens και για τους δύο runners.

• Καταχώριση ενός Project-Specific Runner

Για να καταχωρίσετε έναν project-specific runner, ανοίξτε το έργο σας στο στιγμιότυπο GitLab ή στον λογαριασμό σας στο GitLab SaaS. Από το μενού πλοήγησης στα αριστερά, κάντε κλικ στο στοιχείο Settings και επιλέξτε την επιλογή CI/CD:

Μετά από αυτό, κυλήστε προς τα κάτω στην ενότητα Runners και κάντε κλικ στο κουμπί για να αναπτύξετε την ενότητα:

Η αριστερή πλευρά εξηγεί πώς να καταχωρίσετε έναν project-specific runner. Αυτή είναι μια προβολή του στιγμιοτύπου GitLab SaaS. Μπορείτε επίσης να διαμορφώσετε αυτόματους runners με το Kubernetes, αλλά σε αυτόν τον οδηγό θα χρησιμοποιήσουμε τον χειροκίνητο runner:

Στη συνέχεια, πρέπει να εστιάσετε στην ενότητα όπου σας δίνεται το διακριτικό (token) για αυτό το έργο. Για μια αυτοδιαχειριζόμενη παρουσία GitLab, η διεύθυνση URL θα εμφανίζει τον τομέα του διακομιστή στον οποίο εκτελείται η παρουσία σας GitLab:

Μπορείτε να επιλέξετε να απενεργοποιήσετε τους κοινόχρηστους runners για αυτό το έργο αλλάζοντας τον διακόπτη στη δεξιά ενότητα κάτω από το Shared Runners. Στη συνέχεια, αντιγράψτε το διακριτικό εγγραφής που εμφανίζεται στο σημειωματάριό σας, καθώς θα το χρησιμοποιήσουμε αργότερα.

• Εγγραφή ενός Shared Runner

Για να εγγράψετε έναν κοινόχρηστο runner, πρέπει να συνδεθείτε στην αυτοδιαχειριζόμενη παρουσία σας GitLab ως διαχειριστής. Για να αποκτήσετε πρόσβαση στον πίνακα διαχειριστή, κάντε κλικ στο εικονίδιο γαλλικό κλειδί/κλειδί στο επάνω μενού πλοήγησης:

Στον Admin Panel, κάντε κλικ στο Runners στην ενότητα Overview του αριστερού μενού. Αυτό θα ανοίξει μια σελίδα με τις οδηγίες ρύθμισης των Shared Runners:

Αντιγράψτε το διακριτικό εγγραφής που εμφανίζεται στη δεξιά πλευρά κάτω από το Set up a shared Runner manually. Θα χρησιμοποιήσετε το διακριτικό για να εγγράψετε τον runner στο επόμενο βήμα.

• Σύνδεση ενός GitLab CI Runner με μια Παρουσία GitLab

Σε αυτό το βήμα, θα συνδέσετε την παρουσία σας GitLab με τον CI runner. Συνδεθείτε ξανά στον διακομιστή όπου εγκαταστήσατε την υπηρεσία GitLab runner στο Step Four. Για να ξεκινήσετε τη διαδικασία εγγραφής του runner, εισαγάγετε την ακόλουθη εντολή στο τερματικό σας:

Η εντολή σάς ζητά να απαντήσετε σε μια σειρά ερωτήσεων:

• Εισαγάγετε τη διεύθυνση URL της παρουσίας GitLab (για παράδειγμα, https://gitlab.com/):

Καταχωρίστε το όνομα τομέα της παρουσίας σας GitLab χρησιμοποιώντας https:// για να καθορίσετε SSL.

• Εισαγάγετε το διακριτικό εγγραφής:

Δώστε το διακριτικό εγγραφής σας. Εδώ θα επιλέξετε αν θέλετε αυτός ο runner να είναι συγκεκριμένος για το έργο ή κοινόχρηστος. Μπορείτε να παρέχετε μόνο ένα από τα διακριτικά που αντιγράψατε νωρίτερα για οποιαδήποτε από τις δύο επιλογές.

• Εισαγάγετε μια περιγραφή για τον runner:

Επιλέξτε ένα περιγραφικό όνομα για τον CI runner σας, καθώς θα εμφανίζεται στη διεπαφή χρήστη της παρουσίας GitLab.

• Εισαγάγετε έναν executor: custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes:

Εδώ, σας παρέχει επιλογές για να επιλέξετε έναν executor για την εκτέλεση των εργασιών. Εισαγάγετε Docker.

• Εισαγάγετε ετικέτες για τον runner (διαχωρισμένες με κόμμα):

Αυτό είναι προαιρετικό. Μπορείτε να εισαγάγετε οποιαδήποτε ονόματα ετικετών, όπως εξαρτήσεις που περιλαμβάνει αυτός ο runner. Μπορείτε να το αφήσετε κενό προς το παρόν.

• Εισαγάγετε την προεπιλεγμένη εικόνα Docker (για παράδειγμα, ruby:2.6):

Εδώ, αναμένεται να καθορίσετε μια προεπιλεγμένη εικόνα γενικής χρήσης που χρησιμοποιείται για την εκτέλεση εργασιών σε περίπτωση που το αρχείο gitlab-ci.yml δεν καθορίζει μια εικόνα. Εισαγάγετε alpine:latest καθώς είναι μια μικρή, γενικής χρήσης και ασφαλής εικόνα. Πατήστε enter και ο runner θα εγγραφεί και θα ξεκινήσει αυτόματα:

Για να δείτε τη λίστα των runners που είναι διαθέσιμοι αυτήν τη στιγμή, εισαγάγετε την ακόλουθη εντολή:

Βήμα 6: Επιβεβαίωση ότι ο CI Runner έχει συνδεθεί επιτυχώς στο GitLab

Στη συνέχεια, επιστρέψτε στο πρόγραμμα περιήγησής σας και επισκεφθείτε τη σελίδα του έργου σας στην παρουσία GitLab. Ανάλογα με το πόσα λεπτά έχουν περάσει από τότε που εγγράψατε τον runner, ενδέχεται να δείτε ότι η εργασία εκτελείται αυτήν τη στιγμή:

Ή μπορεί να έχει ολοκληρωθεί:

Μετά από αυτό, μεταβείτε στη σελίδα Pipelines είτε μέσω του αριστερού μενού CI/CD > Pipelines, είτε κάνοντας κλικ στο εικονίδιο running, passed, ή failed (εάν η διοχέτευση αντιμετώπισε σφάλματα) για να δείτε την κατάσταση της εκτέλεσης CI. Εδώ μπορούμε να δούμε ότι ένα από τα στάδια (build stage) έχει ολοκληρωθεί επιτυχώς, ενώ ένα εξακολουθεί να εκτελείται:

Στον πίνακα, κάτω από την κεφαλίδα Stages, κάντε κλικ σε ένα από τα εικονίδια σταδίων για να δείτε τις σχετικές εργασίες:

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

Η εργασία εκτελέστηκε και μπορείτε να δείτε την πρόοδο όταν η εντολή npm εγκαθιστούσε τις εξαρτήσεις. Στη δεξιά πλευρά, μπορείτε να δείτε άλλες σχετικές πληροφορίες. Έχετε την επιλογή να κάνετε λήψη των artifacts από την εργασία. Μπορείτε επίσης να κάνετε εναλλαγή μεταξύ των σταδίων για να δείτε άλλες εργασίες από το αναπτυσσόμενο μενού.

Εδώ, μπορείτε να δείτε τις περιπτώσεις δοκιμών μας που εμφανίζονται όταν επιλέγετε την εργασία στο στάδιο δοκιμής (test stage):

Διαθέσιμοι Runners

Στο αριστερό μενού, εάν κάνετε κλικ στο Settings > CI/CD, και αναπτύξετε την ενότητα Runners ενότητα, θα πρέπει να δείτε τον runner που μόλις καταχωρίσατε. Ανάλογα με το αν είχατε καθορίσει ένα token ειδικό για το έργο ή ένα κοινόχρηστο token, ο runner θα εμφανιστεί στην αντίστοιχη ενότητα.

Εδώ μπορείτε να δείτε ότι καταχωρίσαμε ένα token ειδικό για το έργο. Ο runner εμφανίζεται κάτω από το Specific Runners:

Συμπέρασμα

Σε αυτόν τον οδηγό, μάθατε πώς μπορείτε να αυτοματοποιήσετε τις δοκιμές σας με το GitLab CI. Ξεκινήσαμε στήνοντας ένα έργο εφαρμογής Node.js στο GitLab. Το έργο περιλάμβανε ορισμένες περιπτώσεις δοκιμών και ένα gitlab-ci.yml. Μάθαμε ότι το GitLab χρησιμοποιεί το gitlab-ci.yml αρχείο για να καθορίσει τι πρέπει να κάνει όταν ενεργοποιείται. Ένα gitlab-ci.yml αρχείο είναι απλώς ένα αρχείο ρυθμίσεων που περιέχει οδηγίες για τη δημιουργία και τη δοκιμή εφαρμογών, γραμμένο σε YAML μορφή που μπορεί να κατανοήσει ένας GitLab CI runner.

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

Καλή συνέχεια!