GitHub Actions: Βέλτιστες πρακτικές

Αυτό το ζωντανό έγγραφο λειτουργεί ως συλλογή βέλτιστων πρακτικών για τη χρήση του GitHub Actions. Αν έχεις προτάσεις ή προσθήκες, άνοιξε ένα pull request στο GitHub!

• GitHub Actions: Βέλτιστες πρακτικές
  • Συλλογή βέλτιστων πρακτικών
    • Όρισε χρονικά όρια για τα workflows
      • Παράδειγμα
    • Σκέψου αν τα actions (τρίτων) είναι πραγματικά απαραίτητα
    • Περιόρισε το εύρος του token του workflow
      • Παράδειγμα
    • Κλείδωσε τα actions σε SHA
      • Πώς βρίσκεις το SHA του commit
      • Παράδειγμα
    • Κλείδωσε τους runners σε συγκεκριμένη έκδοση
      • Παράδειγμα
    • Σκέψου να ρυθμίσεις μια στρατηγική concurrency
      • Παράδειγμα
    • Σκέψου ποια triggers είναι πραγματικά απαραίτητα
    • Διάβασε τον οδηγό "Security hardening for GitHub Actions"
  • Λίστα ελέγχου για το workflow

Συλλογή βέλτιστων πρακτικών

Όρισε χρονικά όρια για τα workflows

Από προεπιλογή, το GitHub Actions τερματίζει τα workflows μετά από 6 ώρες αν δεν έχουν ολοκληρωθεί μέχρι τότε. Πολλά workflows δεν χρειάζονται ούτε κατά διάνοια τόσο χρόνο για να ολοκληρωθούν, αλλά μερικές φορές προκύπτουν απρόσμενα σφάλματα ή ένα job κολλάει μέχρι να τερματιστεί η εκτέλεση του workflow 6 ώρες μετά την έναρξή της. Γι' αυτό συνιστάται να ορίσεις μικρότερο χρονικό όριο.

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

Αυτό έχει τα εξής πλεονεκτήματα:

• Τα PR δεν θα μένουν μισή μέρα σε εκκρεμότητα με το CI, τα προβλήματα εντοπίζονται νωρίς ή οι εκτελέσεις workflow μπορούν να επανεκκινηθούν.
• Ο αριθμός των συνολικών παράλληλων builds είναι περιορισμένος, και τα κολλημένα jobs δεν θα δημιουργήσουν προβλήματα σε άλλα PR αν ακυρωθούν νωρίς.

Παράδειγμα

jobs:
  configlet:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - [...]

Σκέψου αν τα actions (τρίτων) είναι πραγματικά απαραίτητα

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

Επομένως, καλό είναι να σκεφτείς προσεκτικά αν αξίζει πραγματικά να εισαγάγεις ένα νέο action ή αν είναι καλύτερα να μεταφέρεις τον κώδικα σε ένα (νέο) action υπό τον έλεγχο του Exercism.

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

Τα actions που δημοσιεύονται από το GitHub ή τον οργανισμό του Exercism μπορούν γενικά να θεωρηθούν (σχεδόν) ασφαλή για να συμπεριληφθούν χωρίς ιδιαίτερη σκέψη.

Περιόρισε το εύρος του token του workflow

Από προεπιλογή, το token πρόσβασης που δίνεται στο workflow έχει εκτεταμένα δικαιώματα, τόσο για ανάγνωση όσο και για εγγραφή.

Η αρχή του ελάχιστου προνομίου θα πρέπει να εφαρμόζεται και στα workflows.

Μπορείς να ορίσεις ποια δικαιώματα χρειάζεται ένα workflow, ξεχωριστά για κάθε workflow.

Παράδειγμα

Αν ένα workflow χρειάζεται μόνο να διαβάζει τα περιεχόμενα ενός αποθετηρίου και όχι να γράφει σε αυτό, π.χ. επειδή είναι ένας συνηθισμένος έλεγχος CI, μπορείς να περιορίσεις το token ως εξής:

permissions:
  contents: read

Δες τα GitHub Docs για την πλήρη λίστα δικαιωμάτων.

Κλείδωσε τα actions σε SHA

Όταν χρησιμοποιείς άλλα actions, κλείδωσέ τα σε ένα commit (μέσω του SHA τους), όχι σε ένα branch ή tag. Έτσι διασφαλίζεται ότι ο ίδιος κώδικας θα εκτελείται κάθε φορά, κάτι που δεν είναι εγγυημένο όταν κλειδώνεις σε branch ή tag.

Αυτό έχει δύο οφέλη:

1. Κάνει το build σου σταθερό
2. Αποτρέπει έναν επιτιθέμενο από το να αλλάξει ένα branch/tag ώστε να δείχνει σε κακόβουλο κώδικα

Η μόνη εξαίρεση σε αυτόν τον κανόνα θα μπορούσαν να είναι τα actions που έχουμε φτιάξει εμείς (το Exercism).

Πώς βρίσκεις το SHA του commit

Συνήθως θέλεις να κλειδώσεις στο SHA του commit μιας συγκεκριμένης έκδοσης. Για να βρεις το SHA του commit μιας έκδοσης, πήγαινε στη σελίδα releases του αποθετηρίου του action (π.χ. https://github.com/actions/checkout/releases). Βρες την έκδοση που θέλεις να χρησιμοποιήσεις και κάνε κλικ στο συντομευμένο SHA (π.χ. a12a394) που αναγράφεται στην ενότητα σύνοψης στα αριστερά της έκδοσης. Θα μεταφερθείς τότε στη σελίδα λεπτομερειών της έκδοσης, η οποία αναγράφει το πλήρες SHA του commit που μπορείς να χρησιμοποιήσεις.

Παράδειγμα

- name: Checkout code
  uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846

Κλείδωσε τους runners σε συγκεκριμένη έκδοση

Τα περισσότερα workflows θα εκτελούνται στους υποστηριζόμενους runners του GitHub. Όταν χρησιμοποιείς έναν από αυτούς τους runners, χρησιμοποίησε μια συγκεκριμένη έκδοση αντί για την τελευταία έκδοση.

Έτσι διασφαλίζεται ότι το workflow θα εκτελείται πάντα στον ίδιο runner, κάτι που κάνει το build σου σταθερό.

Παράδειγμα

Χρησιμοποίησε:

runs-on: ubuntu-22.04

αντί για:

runs-on: ubuntu-latest

Σκέψου να ρυθμίσεις μια στρατηγική concurrency

Συχνά δεν είναι απαραίτητο ή χρήσιμο να εκτελείς το CI σε ενδιάμεσα commits αν στο μεταξύ έχει γίνει push σε ένα νεότερο commit.

Μπορείς να ρυθμίσεις μια στρατηγική concurrency ώστε να ακυρώνεις αυτόματα τα workflows που εκτελούνται στο ίδιο context.

Παράδειγμα

Για να ακυρώνεις τα ενδιάμεσα builds σε ένα PR, μπορείς να χρησιμοποιήσεις τις παρακάτω ρυθμίσεις concurrency:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}

Σκέψου ποια triggers είναι πραγματικά απαραίτητα

Διάβασε τον οδηγό "Security hardening for GitHub Actions"

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

Λίστα ελέγχου για το workflow

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