Συχνά πρέπει να φτιάξω έναν αγωγό για την κατασκευή έργων σε Java. Μερικές φορές είναι ανοιχτού κώδικα, μερικές φορές δεν είναι. Πρόσφατα αποφάσισα να δοκιμάσω να μεταφέρω μερικά από τα αποθετήρια μου από το Travis-CI και το TeamCity στο GitHub Actions, και αυτό προέκυψε από αυτό.
Τι θα αυτοματοποιήσουμε;
Πρώτα, χρειαζόμαστε ένα έργο που θα αυτοματοποιήσουμε, ας κάνουμε μια μικρή εφαρμογή σε Spring boot / Java 11 / Maven. Για τους σκοπούς αυτού του άρθρου, δεν θα μας ενδιαφέρει καθόλου η λογική της εφαρμογής· η υποδομή γύρω από την εφαρμογή είναι σημαντική για εμάς, επομένως ένας απλός ελεγκτής REST API θα μας αρκεί.
Μπορείτε να δείτε τις πηγές εδώ: Όλα τα στάδια κατασκευής ενός αγωγού αντικατοπτρίζονται στα αιτήματα έλξης για αυτό το έργο.
JIRA και προγραμματισμός
Αξίζει να πούμε ότι συνήθως χρησιμοποιούμε το JIRA ως παρακολούθηση προβλημάτων, οπότε ας δημιουργήσουμε έναν ξεχωριστό πίνακα για αυτό το έργο και ας προσθέσουμε τα πρώτα ζητήματα εκεί:
Λίγο αργότερα θα επιστρέψουμε στο τι ενδιαφέροντα πράγματα μπορούν να προσφέρουν σε συνδυασμό το JIRA και το GitHub.
Αυτοματοποιούμε τη συναρμολόγηση του έργου
Το δοκιμαστικό μας έργο είναι κατασκευασμένο μέσω της maven, επομένως η κατασκευή του είναι αρκετά απλή, το μόνο που χρειαζόμαστε είναι το πακέτο mvn clean.
Για το το κάνουμε στο .github/ directory workflow/ file build.yml στο οποίο θα περιγράψουμε τις ενέργειες κατά τη δημιουργία του κύριου κλάδου:
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean package -DskipTests
on — αυτή είναι μια περιγραφή της εκδήλωσης στην οποία θα κυκλοφορήσει το σενάριό μας.
on: pull_request/push — υποδηλώνει ότι αυτή η ροή εργασίας πρέπει να εκκινείται κάθε φορά που γίνεται μια ώθηση στην κύρια και δημιουργούνται αιτήματα έλξης.
Ακολουθεί μια περιγραφή των εργασιών (θέσεις εργασίας) και βήματα εκτέλεσης (βήματα) για κάθε εργασία.
τρέχει-σε - εδώ μπορούμε να επιλέξουμε το λειτουργικό σύστημα προορισμού, παραδόξως, μπορείτε να επιλέξετε ακόμη και Mac OS, αλλά σε ιδιωτικά αποθετήρια αυτό είναι αρκετά ακριβό (σε σύγκριση με το Linux).
χρησιμοποιεί σας επιτρέπει να επαναχρησιμοποιήσετε άλλες ενέργειες, για παράδειγμα, χρησιμοποιώντας την ενέργεια actions/setup-java εγκαθιστούμε το περιβάλλον για Java 11.
Μέσω με μπορούμε να καθορίσουμε τις παραμέτρους με τις οποίες εκκινούμε την ενέργεια, ουσιαστικά αυτά είναι τα ορίσματα που θα περάσουν στην ενέργεια.
Το μόνο που μένει είναι να εκτελέσετε την κατασκευή του έργου με τον Maven: run: mvn -B clean package σημαία -B λέει ότι χρειαζόμαστε μια μη διαδραστική λειτουργία, έτσι ώστε το Maven ξαφνικά να μην θέλει να μας ρωτήσει κάτι
Εξαιρετική! Τώρα, κάθε φορά που δεσμεύεστε στον κύριο, ξεκινά η κατασκευή του έργου.
Αυτοματοποίηση δοκιμαστικών εκκινήσεων
Η συναρμολόγηση είναι καλή, αλλά στην πραγματικότητα, ένα έργο μπορεί να συναρμολογηθεί με ασφάλεια, αλλά όχι να λειτουργήσει. Επομένως, το επόμενο βήμα είναι να αυτοματοποιήσετε τις δοκιμαστικές εκτελέσεις. Επιπλέον, είναι πολύ βολικό να βλέπετε τα αποτελέσματα της επιτυχίας των δοκιμών όταν κάνετε μια αναθεώρηση δημοσίων σχέσεων - γνωρίζετε σίγουρα ότι οι δοκιμές περνούν και κανείς δεν ξέχασε να εκτελέσει το υποκατάστημά του πριν κάνει μια συγχώνευση.
Θα εκτελέσουμε δοκιμές κατά τη δημιουργία ενός αιτήματος έλξης και θα συγχωνευθούμε στο κύριο, και ταυτόχρονα θα προσθέσουμε τη δημιουργία μιας αναφοράς για την κάλυψη κωδικού.
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Verify
run: mvn -B clean verify
- name: Test Coverage
uses: codecov/codecov-action@v1
with:
token: ${{ secrets.CODECOV_TOKEN }}
Για την κάλυψη δοκιμών, χρησιμοποιώ το codecov σε συνδυασμό με το πρόσθετο jacoco. Το codecov έχει τη δική του δράση, αλλά χρειάζεται ένα διακριτικό για να λειτουργήσει με το αίτημα έλξης:
${{ secrets.CODECOV_TOKEN }} — θα δούμε αυτήν την κατασκευή περισσότερες από μία φορές, τα μυστικά είναι ένας μηχανισμός αποθήκευσης μυστικών στο GitHub, μπορούμε να γράψουμε εκεί κωδικούς πρόσβασης/tokens/host/url και άλλα δεδομένα που δεν πρέπει να περιλαμβάνονται στη βάση κώδικα του αποθετηρίου.
Μπορείτε να προσθέσετε μια μεταβλητή στα μυστικά στις ρυθμίσεις αποθετηρίου στο GitHub:
Μπορείτε να πάρετε ένα διακριτικό στο Μετά την εξουσιοδότηση μέσω του GitHub, για να προσθέσετε ένα δημόσιο έργο, πρέπει απλώς να ακολουθήσετε έναν σύνδεσμο όπως αυτός: /[όνομα repo]. Μπορεί επίσης να προστεθεί ένα ιδιωτικό αποθετήριο· για να γίνει αυτό, πρέπει να δώσετε δικαιώματα codecov στην εφαρμογή στο Github.
Προσθέστε το πρόσθετο jacoco στο αρχείο POM:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<!-- attached to Maven test phase -->
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<reportFormat>plain</reportFormat>
<includes>
<include>**/*Test*.java</include>
<include>**/*IT*.java</include>
</includes>
</configuration>
</plugin>
Τώρα το codecov bot θα εισαγάγει κάθε μας αίτημα έλξης και θα προσθέσει ένα γράφημα αλλαγής κάλυψης:
Ας προσθέσουμε έναν στατικό αναλυτή
Στα περισσότερα από τα έργα ανοιχτού κώδικα που χρησιμοποιώ χρησιμοποιώ το σόναρ για ανάλυση στατικού κώδικα, είναι αρκετά εύκολο να συνδεθώ με το travis-ci. Επομένως, είναι ένα λογικό βήμα κατά τη μετεγκατάσταση στο GitHub Actions να κάνετε το ίδιο. Η αγορά δράσης είναι ένα ωραίο πράγμα, αλλά αυτή τη φορά με απογοήτευσε λίγο, γιατί από συνήθεια βρήκα τη δράση που χρειαζόμουν και την πρόσθεσα στη ροή εργασίας. Αλλά αποδείχθηκε ότι το σόναρ δεν υποστηρίζει την εργασία μέσω μιας δράσης για την ανάλυση έργων στο maven ή στο gradle. Φυσικά, αυτό γράφεται στην τεκμηρίωση, αλλά ποιος το διαβάζει;!
Δεν είναι δυνατό μέσω μιας ενέργειας, επομένως θα το κάνουμε μέσω της προσθήκης mvn:
name: SonarCloud
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
runs-on: ubuntu-16.04
steps:
- uses: actions/checkout@v1
- name: Set up JDK
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Analyze with SonarCloud
# set environment variables:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# run sonar maven plugin:
run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml
SONAR_TOKEN - μπορεί να ληφθεί στο και πρέπει να το καταχωρήσεις μυστικά. GITHUB_TOKEN - αυτό είναι ένα ενσωματωμένο διακριτικό που δημιουργεί το GitHub, με τη βοήθεια του οποίου το sonarcloud[bot] θα μπορεί να συνδεθεί στο Git για να μας αφήνει μηνύματα σε αιτήματα έλξης.
Dsonar.projectKey — το όνομα του έργου στο βυθόμετρο, μπορείτε να το δείτε στις ρυθμίσεις του έργου.
Dsonar.οργάνωση — όνομα του οργανισμού από το GitHub.
Κάνουμε ένα αίτημα έλξης και περιμένουμε να έρθει το sonarcloud[bot] στα σχόλια:
Διαχείριση έκδοσης
Η έκδοση έχει διαμορφωθεί, οι δοκιμές έχουν εκτελεστεί και μπορούμε να κάνουμε μια κυκλοφορία. Ας δούμε πώς οι Ενέργειες GitHub μπορούν να κάνουν τη διαχείριση εκδόσεων πολύ πιο εύκολη.
Στη δουλειά, έχω έργα των οποίων η βάση κώδικα είναι σε bitbucket (όλα είναι όπως σε αυτήν την ιστορία «Γράφω στο bitbucket τη μέρα, δεσμεύομαι στο GitHub τη νύχτα»). Δυστυχώς, το bitbucket δεν διαθέτει ενσωματωμένα εργαλεία διαχείρισης εκδόσεων. Αυτό είναι ένα πρόβλημα, γιατί για κάθε κυκλοφορία πρέπει να δημιουργείτε με μη αυτόματο τρόπο μια σελίδα σε συρροή και να ρίχνετε εκεί όλες τις δυνατότητες που περιλαμβάνονται στην έκδοση, να αναζητάτε τα παλάτια του μυαλού, τις εργασίες στο jira, τις δεσμεύσεις στο αποθετήριο. Υπάρχουν πολλές πιθανότητες να κάνετε λάθος, μπορείτε να ξεχάσετε κάτι ή να εισαγάγετε κάτι που είχε ήδη κυκλοφορήσει την τελευταία φορά, μερικές φορές απλά δεν είναι σαφές τι να ταξινομήσετε ως αίτημα έλξης - είναι ένα χαρακτηριστικό ή μια διόρθωση σφαλμάτων ή δοκιμές επεξεργασίας ή κάτι υποδομή.
Πώς μπορούν να μας βοηθήσουν οι ενέργειες του GitHub; Υπάρχει μια εξαιρετική δράση - σύνταξη έκδοσης, σας επιτρέπει να ορίσετε ένα πρότυπο αρχείου σημειώσεων έκδοσης για να ορίσετε κατηγορίες αιτημάτων έλξης και να τις ομαδοποιήσετε αυτόματα στο αρχείο σημειώσεων έκδοσης:
Παράδειγμα προτύπου για τη ρύθμιση μιας αναφοράς (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' New Features'
labels:
- 'type:features'
# в эту категорию собираем все PR с меткой type:features
- title: ' Bugs Fixes'
labels:
- 'type:fix'
# аналогично для метки type:fix и т.д.
- title: ' Documentation'
labels:
- 'type:documentation'
- title: ' Configuration'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Changes
$CHANGES
Προσθέστε ένα σενάριο για να δημιουργήσετε μια πρόχειρη έκδοση (.github/workflows/release-draft.yml):
name: "Create draft release"
on:
push:
branches:
- master
jobs:
update_draft_release:
runs-on: ubuntu-18.04
steps:
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Όλα τα αιτήματα έλξης από εδώ και στο εξής θα συλλέγονται αυτόματα στις σημειώσεις έκδοσης - μαγικό!
Εδώ μπορεί να προκύψει το ερώτημα: τι γίνεται αν οι προγραμματιστές ξεχάσουν να βάλουν ετικέτες στο PR; Μετά δεν είναι ξεκάθαρο σε ποια κατηγορία να το βάλεις και πάλι θα πρέπει να το αντιμετωπίσεις χειροκίνητα, με κάθε PR ξεχωριστά. Για να επιλύσουμε αυτό το πρόβλημα, μπορούμε να χρησιμοποιήσουμε μια άλλη ενέργεια - τον επαληθευτή ετικετών - που ελέγχει την παρουσία ετικετών στο αίτημα έλξης. Εάν δεν υπάρχουν απαιτούμενες ετικέτες, τότε ο έλεγχος θα αποτύχει και θα δούμε ένα μήνυμα σχετικά με αυτό στο αίτημα έλξης μας.
name: "Verify type labels"
on:
pull_request:
types: [opened, labeled, unlabeled, synchronize]
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: zwaldowski/match-label-action@v2
with:
allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'
Τώρα κάθε αίτημα έλξης πρέπει να επισημαίνεται με μία από τις ετικέτες: type:fix, type:features, type:documentation, type:tests, type:config.
Αυτόματος σχολιασμός των αιτημάτων έλξης
Δεδομένου ότι θίξαμε ένα τέτοιο θέμα όπως η αποτελεσματική εργασία με αιτήματα έλξης, αξίζει να μιλήσουμε για μια τέτοια ενέργεια όπως το labeler, βάζει ετικέτες στο PR με βάση τα αρχεία που έχουν αλλάξει. Για παράδειγμα, μπορούμε να επισημάνουμε ως [build] οποιοδήποτε αίτημα έλξης που περιέχει αλλαγές στον κατάλογο .github/workflow.
Η σύνδεσή του είναι αρκετά απλή:
name: "Auto-assign themes to PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Χρειαζόμαστε επίσης ένα αρχείο που να περιγράφει την αντιστοιχία μεταξύ των καταλόγων του έργου και των θεμάτων του αιτήματος έλξης:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Δεν κατάφερα να συνδυάσω την ενέργεια που τοποθετεί αυτόματα ετικέτες σε αιτήματα έλξης με την ενέργεια που ελέγχει την ύπαρξη απαιτούμενων ετικετών. Το match-label δεν θέλει να δει τις ετικέτες που προστέθηκαν από το bot. Φαίνεται πιο εύκολο να γράψετε τη δική σας δράση που να συνδυάζει και τα δύο στάδια. Αλλά ακόμη και σε αυτή τη μορφή είναι αρκετά βολικό στη χρήση· πρέπει να επιλέξετε μια ετικέτα από τη λίστα όταν δημιουργείτε ένα αίτημα έλξης.
Είναι ώρα για ανάπτυξη
Δοκίμασα πολλές επιλογές ανάπτυξης μέσω GitHub Actions (μέσω ssh, μέσω scp και χρησιμοποιώντας docker-hub) και μπορώ να πω ότι, πιθανότατα, θα βρείτε έναν τρόπο να ανεβάσετε το δυαδικό στον διακομιστή, ανεξάρτητα από το πόσο στραβός είναι ο σωλήνας σας είναι.
Μου άρεσε η επιλογή της διατήρησης ολόκληρης της υποδομής σε ένα μέρος, οπότε ας δούμε πώς να αναπτύξουμε τα πακέτα GitHub (αυτό είναι ένα αποθετήριο για δυαδικό περιεχόμενο, npm, jar, docker).
Σενάριο για τη δημιουργία μιας εικόνας docker και τη δημοσίευσή της στα πακέτα GitHub:
name: Deploy docker image
on:
push:
branches:
- 'master'
jobs:
build_docker_image:
runs-on: ubuntu-18.04
steps:
# Build JAR:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean compile package -DskipTests
# Set global environment variables:
- name: set global env
id: global_env
run: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"
# Build Docker image:
- name: Build and tag image
run: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- name: Docker login
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publish image to github package repository:
- name: Publish image
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Αρχικά, πρέπει να δημιουργήσουμε το αρχείο JAR της εφαρμογής μας, μετά από το οποίο υπολογίζουμε τη διαδρομή προς το μητρώο docker του GitHub και το όνομα της εικόνας μας. Εδώ υπάρχουν μερικά κόλπα που δεν έχουμε συναντήσει ακόμα:
- μια κατασκευή όπως: echo “::set-output name=NAME::VALUE” σας επιτρέπει να ορίσετε την τιμή μιας μεταβλητής στο τρέχον βήμα, έτσι ώστε να μπορεί στη συνέχεια να διαβαστεί σε όλα τα άλλα βήματα.
- μπορείτε να λάβετε την τιμή του συνόλου της μεταβλητής στο προηγούμενο βήμα μέσω του αναγνωριστικού αυτού του βήματος: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Η τυπική μεταβλητή GITHUB_REPOSITORY αποθηκεύει το όνομα του αποθετηρίου και του κατόχου του ("ιδιοκτήτης/επώνυμο"). Για να κόψουμε τα πάντα από αυτήν τη γραμμή εκτός από το όνομα του αποθετηρίου, θα χρησιμοποιήσουμε τη σύνταξη bash: ${GITHUB_REPOSITORY#*/}
Στη συνέχεια πρέπει να δημιουργήσουμε την εικόνα docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Συνδεθείτε στο μητρώο:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Και δημοσιεύστε την εικόνα στο GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Για να υποδείξουμε την έκδοση της εικόνας, χρησιμοποιούμε τα πρώτα ψηφία από τον κατακερματισμό SHA της δέσμευσης - GITHUB_SHA υπάρχουν επίσης αποχρώσεις εδώ, εάν κάνετε τέτοιες κατασκευές όχι μόνο κατά τη συγχώνευση στο κύριο, αλλά και σύμφωνα με τη δημιουργία αιτήματος έλξης γεγονός, τότε το SHA μπορεί να μην ταιριάζει με τον κατακερματισμό που βλέπουμε στο ιστορικό git, επειδή η ενέργεια ενεργειών/checkout κάνει το δικό της μοναδικό κατακερματισμό για να αποφύγει τις ενέργειες αδιεξόδου στο PR.
Εάν όλα πήγαν καλά, τότε ανοίγοντας την ενότητα πακέτων (https://github.com/antkorwin/github-actions/packages) στο αποθετήριο, θα δείτε μια νέα εικόνα docker:
Εκεί μπορείτε επίσης να δείτε μια λίστα με εκδόσεις της εικόνας docker.
Το μόνο που μένει είναι να διαμορφώσουμε τον διακομιστή μας ώστε να λειτουργεί με αυτό το μητρώο και να επανεκκινήσουμε την υπηρεσία. Μάλλον θα μιλήσω για το πώς να το κάνω αυτό μέσω του systemd άλλη φορά.
Παρακολούθηση
Ας δούμε μια απλή επιλογή για το πώς να κάνουμε έναν έλεγχο υγείας για την εφαρμογή μας χρησιμοποιώντας το GitHub Actions. Η εφαρμογή εκκίνησης μας διαθέτει ενεργοποιητή, επομένως δεν χρειάζεται καν να γράψουμε ένα API για να ελέγξουμε την κατάστασή του· έχουμε ήδη κάνει τα πάντα για τους τεμπέληδες. Απλά πρέπει να τραβήξετε τον κεντρικό υπολογιστή: SERVER-URL:PORT/actuator/health
$ curl -v 127.0.0.1:8080/actuator/health
> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*
< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT
{"status":"UP"}
Το μόνο που χρειαζόμαστε είναι να γράψουμε μια εργασία για να ελέγξουμε τον διακομιστή χρησιμοποιώντας το cron και αν ξαφνικά δεν μας απαντήσει, τότε θα στείλουμε μια ειδοποίηση μέσω τηλεγραφήματος.
Αρχικά, ας καταλάβουμε πώς να εκτελέσετε μια ροή εργασίας cron:
on:
schedule:
- cron: '*/5 * * * *'
Είναι απλό, δεν μπορώ καν να πιστέψω ότι στο Github μπορείτε να δημιουργήσετε συμβάντα που δεν ταιριάζουν καθόλου σε webhook. Λεπτομέρειες υπάρχουν στην τεκμηρίωση:
Ας ελέγξουμε την κατάσταση του διακομιστή χειροκίνητα μέσω curl:
jobs:
ping:
runs-on: ubuntu-18.04
steps:
- name: curl actuator
id: ping
run: |
echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"
- name: health check
run: |
if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
echo "health check is failed"
exit 1
fi
echo "It's OK"
Αρχικά, αποθηκεύουμε σε μια μεταβλητή αυτό που απάντησε ο διακομιστής στο αίτημα, στο επόμενο βήμα ελέγχουμε ότι η κατάσταση είναι UP και, αν δεν συμβαίνει αυτό, τότε βγαίνουμε με σφάλμα. Εάν πρέπει να «συντρίψετε» μια ενέργεια με τα χέρια σας, τότε έξοδος 1 - κατάλληλο όπλο.
- name: send alert in telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Health check of the:
${{secrets.SERVER_HOST}}/api/actuator/health
failed with the result:
${{ steps.ping.outputs.status }}
Στέλνουμε στο τηλεγράφημα μόνο εάν η ενέργεια απέτυχε στο προηγούμενο βήμα. Για να στείλουμε ένα μήνυμα χρησιμοποιούμε το appleboy/telegram-action. Μπορείτε να διαβάσετε για το πώς να αποκτήσετε ένα διακριτικό bot και ένα αναγνωριστικό συνομιλίας στην τεκμηρίωση:
Μην ξεχάσετε να γράψετε στα μυστικά στο Github: URL για τον διακομιστή και διακριτικά για το bot του telegram.
Μπόνους κομμάτι - JIRA για τεμπέληδες
Υποσχέθηκα ότι θα επιστρέψουμε στο JIRA, και επιστρέψαμε. Εκατοντάδες φορές έχω παρατηρήσει μια κατάσταση στα stand-ups όταν οι προγραμματιστές δημιούργησαν μια δυνατότητα, συγχώνευσαν έναν κλάδο, αλλά ξέχασαν να σύρουν το ζήτημα στο JIRA. Φυσικά, αν όλα αυτά γίνονταν σε ένα μέρος, θα ήταν πιο εύκολο, αλλά στην πραγματικότητα γράφουμε κώδικα στο IDE, συγχωνεύουμε κλάδους στο bitbucket ή στο GitHub και μετά σύρουμε τις εργασίες στο Jira, για αυτό πρέπει να ανοίξουμε νέα παράθυρα , μερικές φορές συνδεθείτε ξανά και κ.λπ. Όταν θυμάστε τέλεια τι πρέπει να κάνετε στη συνέχεια, τότε δεν έχει νόημα να ανοίξετε ξανά τον πίνακα. Ως αποτέλεσμα, το πρωί σε μια στάση πρέπει να αφιερώσετε χρόνο για να ενημερώσετε τον πίνακα εργασιών.
Το GitHub θα μας βοηθήσει επίσης σε αυτήν τη συνηθισμένη εργασία· για αρχή, μπορούμε να σύρουμε τα προβλήματα αυτόματα στη στήλη code_review όταν υποβάλλουμε ένα αίτημα έλξης. Το μόνο που χρειάζεται να κάνετε είναι να ακολουθήσετε τη σύμβαση ονομασίας κλάδου:
[имя проекта]-[номер таска]-название
για παράδειγμα, εάν το κλειδί έργου "GitHub Actions" είναι GA, τότε GA-8-jira-bot θα μπορούσε να είναι ένας κλάδος για την υλοποίηση της εργασίας GA-8.
Η ενσωμάτωση με το JIRA λειτουργεί μέσω ενεργειών από το Atlassian, δεν είναι τέλειες, πρέπει να πω ότι μερικές από αυτές δεν μου βοήθησαν καθόλου. Αλλά θα συζητήσουμε μόνο εκείνα που σίγουρα λειτουργούν και χρησιμοποιούνται ενεργά.
Πρώτα πρέπει να συνδεθείτε στο JIRA χρησιμοποιώντας την ενέργεια: atlassian/gajira-login
jobs:
build:
runs-on: ubuntu-latest
name: Jira Workflow
steps:
- name: Login
uses: atlassian/gajira-login@master
env:
JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
Για να το κάνετε αυτό, πρέπει να λάβετε ένα διακριτικό στο JIRA, πώς να το κάνετε αυτό περιγράφεται εδώ:
Εξάγουμε το αναγνωριστικό εργασίας από το όνομα κλάδου:
- name: Find Issue
id: find_issue
shell: bash
run: |
echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo brach name: $GITHUB_HEAD_REF
echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- name: Check Issue
shell: bash
run: |
if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
exit 1
fi
echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
Εάν κάνετε αναζήτηση στην αγορά GitHub, μπορείτε να βρείτε μια ενέργεια για αυτήν την εργασία, αλλά έπρεπε να γράψω το ίδιο πράγμα χρησιμοποιώντας grep χρησιμοποιώντας το όνομα του κλάδου, επειδή αυτή η ενέργεια από το Atlassian δεν ήθελε να λειτουργήσει με κανέναν τρόπο στο έργο μου , για να καταλάβετε τι ήταν λάθος εκεί - περισσότερο από το να κάνετε το ίδιο πράγμα με τα χέρια σας.
Το μόνο που απομένει είναι να μετακινήσετε την εργασία στη στήλη "Επισκόπηση κώδικα" κατά τη δημιουργία ενός αιτήματος έλξης:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Υπάρχει μια ειδική ενέργεια για αυτό στο GitHub, το μόνο που χρειάζεται είναι το αναγνωριστικό ζητήματος που αποκτήθηκε στο προηγούμενο βήμα και η εξουσιοδότηση στο JIRA που κάναμε παραπάνω.
Με τον ίδιο τρόπο, μπορείτε να σύρετε εργασίες κατά τη συγχώνευση στο κύριο, και άλλα συμβάντα από τη ροή εργασίας GitHub. Γενικά, όλα εξαρτώνται από τη φαντασία και την επιθυμία σας να αυτοματοποιήσετε τις διαδικασίες ρουτίνας.
Ευρήματα
Αν κοιτάξετε το κλασικό διάγραμμα DEVOPS, έχουμε καλύψει όλα τα στάδια, εκτός ίσως από τη λειτουργία, νομίζω ότι αν προσπαθήσετε, μπορείτε να βρείτε κάποια ενέργεια στην αγορά για ενσωμάτωση με το σύστημα υποστήριξης, οπότε θα υποθέσουμε ότι ο αγωγός γύρισε να είναι ενδελεχής και μπορούν να εξαχθούν συμπεράσματα με βάση τη χρήση του.
Πλεονεκτήματα:
- Αγορά με έτοιμες δράσεις για όλες τις περιστάσεις, αυτό είναι πολύ ωραίο. Στα περισσότερα από αυτά, μπορείτε επίσης να δείτε τον πηγαίο κώδικα για να κατανοήσετε πώς να λύσετε ένα παρόμοιο πρόβλημα ή να δημοσιεύσετε ένα αίτημα δυνατότητας στον συγγραφέα απευθείας στο αποθετήριο GitHub.
- Η επιλογή της πλατφόρμας στόχου για συναρμολόγηση: Linux, mac os, windows είναι ένα αρκετά ενδιαφέρον χαρακτηριστικό.
- Τα πακέτα Github είναι ένα εξαιρετικό πράγμα, είναι βολικό να διατηρείτε ολόκληρη την υποδομή σε ένα μέρος, δεν χρειάζεται να σερφάρετε σε διαφορετικά παράθυρα, όλα βρίσκονται σε ακτίνα ενός ή δύο κλικ του ποντικιού και είναι τέλεια ενσωματωμένα με το GitHub Actions. Η υποστήριξη μητρώου Docker στη δωρεάν έκδοση είναι επίσης ένα καλό πλεονέκτημα.
- Το GitHub κρύβει μυστικά στα αρχεία καταγραφής, επομένως η χρήση του για την αποθήκευση κωδικών πρόσβασης και διακριτικών δεν είναι τόσο τρομακτική. Σε όλα τα πειράματά μου, δεν μπόρεσα ποτέ να δω το μυστικό στην καθαρή του μορφή στην κονσόλα.
- Δωρεάν για έργα ανοιχτού κώδικα
Μειονεκτήματα:
- YML, καλά, δεν μου αρέσει. Όταν εργάζεστε με μια τέτοια ροή, το πιο συνηθισμένο μήνυμα δέσμευσης που έχω είναι "διορθώστε τη μορφή yml", τότε ξεχνάτε να βάλετε μια καρτέλα κάπου ή τη γράφετε σε λάθος γραμμή. Γενικά, το να κάθεσαι μπροστά σε μια οθόνη με μοιρογνωμόνιο και χάρακα δεν είναι η πιο ευχάριστη εμπειρία.
- Ο DEBUG, ο εντοπισμός σφαλμάτων της ροής με commits, η εκτέλεση μιας ανακατασκευής και η έξοδος στην κονσόλα δεν είναι πάντα βολικό, αλλά είναι περισσότερο της κατηγορίας "είσαι υπερβολικός", έχετε συνηθίσει να εργάζεστε με βολικό IDEA, όταν μπορείτε να διορθώσετε οτιδήποτε .
- Μπορείτε να γράψετε τη δράση σας σε οτιδήποτε αν το τυλίξετε σε Docker, αλλά μόνο η javascript υποστηρίζεται εγγενώς, φυσικά αυτό είναι θέμα γούστου, αλλά θα προτιμούσα κάτι άλλο αντί για js.
Να σας υπενθυμίσω ότι το αποθετήριο με όλα τα σενάρια είναι εδώ:
Την επόμενη εβδομάδα θα εμφανιστώ μαζί στο συνέδριο Heisenbug 2020 Piter. Θα σας πω όχι μόνο πώς να αποφύγετε λάθη κατά την προετοιμασία των δεδομένων δοκιμής, αλλά και να μοιραστώ τα μυστικά μου για την εργασία με σύνολα δεδομένων σε εφαρμογές Java!
Πηγή: www.habr.com