Τι είναι οι ενέργειες του Github και πώς μπορείτε να αυτοματοποιήσετε τις δοκιμές και τις αργές ειδοποιήσεις;

Ο αυτοματισμός είναι ένα ισχυρό εργαλείο. Και μας εξοικονομεί χρόνο και μπορεί να συμβάλει στη μείωση του ανθρώπινου λάθους.

Αλλά ο αυτοματισμός μπορεί να είναι σκληρός και μερικές φορές μπορεί να αποδειχθεί δαπανηρός. Πώς μπορούν οι ενέργειες Github Actions να σκληρύνουν τον κώδικα μας και να μας δώσουν περισσότερο χρόνο για να δουλέψουμε σε λειτουργίες αντί για σφάλματα;

  • Τι είναι οι δράσεις Github;
  • Τι είναι το CI / CD;
  • Τι πρόκειται να οικοδομήσουμε;
  • Μέρος 0: Δημιουργία έργου
  • Μέρος 1: Αυτοματοποίηση δοκιμών
  • Μέρος 2: Δημοσίευση νέων αιτημάτων έλξης στο Slack

Τι είναι οι δράσεις Github;

Οι ενέργειες είναι μια σχετικά νέα δυνατότητα για το Github που σας επιτρέπει να ρυθμίσετε ροές εργασίας CI / CD χρησιμοποιώντας ένα αρχείο διαμόρφωσης απευθείας στο repo του Github.

Προηγουμένως, εάν θέλετε να ρυθμίσετε οποιοδήποτε είδος αυτοματισμού με δοκιμές, κατασκευές ή αναπτύξεις, θα πρέπει να αναζητήσετε υπηρεσίες όπως το Circle CI και το Travis ή να γράψετε τα δικά σας σενάρια. Αλλά με το Actions, έχετε υποστήριξη πρώτης τάξεως σε ισχυρά εργαλεία για την αυτοματοποίηση της ροής εργασίας σας.

Τι είναι το CI / CD;

Το CD / CD σημαίνει συνεχή ολοκλήρωση και συνεχή ανάπτυξη (ή μπορεί να είναι συνεχής παράδοση). Είναι και οι δύο πρακτικές στην ανάπτυξη λογισμικού που επιτρέπουν στις ομάδες να δημιουργούν έργα μαζί γρήγορα, αποτελεσματικά και ιδανικά με λιγότερα λάθη.

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

Η συνεχής ανάπτυξη κάνει αυτό ένα βήμα παραπέρα και μεταφέρει αυτόν τον αυτοματισμό στο επίπεδο ανάπτυξης. Όπου με τη διαδικασία CI, αυτοματοποιείτε τη δοκιμή και το κτίριο, η συνεχής ανάπτυξη θα αυτοματοποιήσει την ανάπτυξη του έργου σε ένα περιβάλλον.

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

Τι πρόκειται να οικοδομήσουμε;

Θα αντιμετωπίσουμε δύο διαφορετικές ροές εργασίας.

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

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

Μέρος 0: Δημιουργία έργου

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

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

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

git clone --single-branch --branch start [email protected]:colbyfayock/my-github-actions.git 

Μόλις το κλωνοποιήσετε τοπικά και εγκαταστήσετε τις εξαρτήσεις, θα πρέπει να μπορείτε να εκτελέσετε τις δοκιμές και να τις δείτε να περνούν!

Θα πρέπει επίσης να σημειωθεί ότι θα πρέπει να προσθέσετε αυτό το έργο ως νέο αποθετήριο στο Github για να το ακολουθήσετε.

Ακολουθήστε μαζί με τη δέσμευση!

Μέρος 1: Αυτοματοποίηση δοκιμών

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

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

Βήμα 1: Δημιουργία νέας ενέργειας

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

Θα ξεκινήσουμε μεταβαίνοντας στην καρτέλα Ενέργειες στη σελίδα αποθετηρίου μας.

Μόλις φτάσουμε εκεί, θα δούμε αμέσως μερικές ροές εργασίας εκκίνησης με τις οποίες το Github μας επιτρέπει να βυθίσουμε. Εφόσον χρησιμοποιούμε ένα έργο κόμβου, μπορούμε να προχωρήσουμε και να κάνουμε κλικ στην επιλογή Ρύθμιση αυτής της ροής εργασίας κάτω από τη ροή εργασίας Node.js.

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

Στην πραγματικότητα πρόκειται να το αφήσουμε "ως έχει" για το πρώτο μας βήμα. Προαιρετικά, μπορείτε να αλλάξετε το όνομα του αρχείου tests.ymlή κάτι που θα θυμάστε.

Μπορείτε να προχωρήσετε και να κάνετε κλικ στο κουμπί Έναρξη δέσμευσης και στη συνέχεια είτε να τον δεσμεύσετε στον κατάλογο masterείτε να προσθέσετε την αλλαγή σε έναν νέο κλάδο. Για αυτήν την καθοδήγηση, θα δεσμευτώ κατ 'ευθείαν master.

To see our new action run, we can again click on the Actions tab which will navigate us back to our new Actions dashboard.

From there, you can click on Node.js CI and select the commit that you just made above and you'll land on our new action dashboard. You can then click one of the node versions in the sidebar via build (#.x), click the Run npm test dropdown, and we'll be able to see the output of our tests being run (which if you're following along with me, should pass!).

Follow along with the commit!

Step 2: Configuring our new action

So what did we just do above? We'll walk through the configuration file and what we can customize.

Starting from the top, we specify our name:

name: Node.js CI 

This can really be whatever you want. Whatever you pick should help you remember what it is. I'm going to customize this to "Tests" so I know exactly what's going on.

on: push: branches: [ master ] pull_request: branches: [ master ] 

The on key is how we specify what events trigger our action. This can be a variety of things like based on time with cron. But here, we're saying that we want this action to run any time someone pushes commits to  master or someone creates a pull request targeting the master branch. We're not going to make a change here.

jobs: build: runs-on: ubuntu-latest 

This next bit creates a new job called build. Here we're saying that we want to use the latest version of Ubuntu to run our tests on. Ubuntu is common, so you'll only want to customize this if you want to run it on a specific environment.

 strategy: matrix: node-version: [10.x, 12.x, 14.x] 

Inside of our job we specify a strategy matrix. This allows us to run the same tests on a few different variations.

In this instance, we're running the tests on 3 different versions of node to make sure it works on all of them. This is definitely helpful to make sure your code is flexible and future proof, but if you're building and running your code on a specific node version, you're safe to change this to only that version.

 steps: - uses: actions/[email protected] - name: Use Node.js ${{ matrix.node-version }} uses: actions/[email protected] with: node-version: ${{ matrix.node-version }} - run: npm ci - run: npm run build --if-present - run: npm test 

Finally, we specify the steps we want our job to run. Breaking this down:

  • uses: actions/[email protected]: In order for us to run our code, we need to have it available. This checks out our code on our job environment so we can use it to run tests.
  • uses: actions/[email protected]: Since we're using node with our project, we'll need it set up on our environment. We're using this action to do that setup  for us for each version we've specified in the matrix we configured above.
  • run: npm ci: If you're not familiar with npm ci, it's similar to running npm install but uses the package-lock.json file without performing any patch upgrades. So essentially, this installs our dependencies.
  • run: npm run build --if-present: npm run build runs the build script in our project. The --if-present flag performs what it sounds like and only runs this command if the build script is present. It doesn't hurt anything to leave this in as it won't run without the script, but feel free to remove this as we're not building the project here.
  • run: npm test: Finally, we run npm test to run our tests. This uses the test npm script set up in our package.json file.

And with that, we've made a few tweaks, but our tests should run after we've committed those changes and pass like before!

Follow along with the commit!

Step 3: Testing that our tests fail and prevent merges

Now that our tests are set up to automatically run, let's try to break it to see it work.

At this point, you can really do whatever you want to intentionally break the tests, but here's what I did:

I'm intentionally returning different expected output so that my tests will fail. And they do!

In my new pull request, my new branch breaks the tests, so it tells me my checks have failed. If you noticed though, it's still green to merge, so how can we prevent merges?

We can prevent pull requests from being merged by setting up a Protected Branch in our project settings.

First, navigate to Settings, then Branches, and click Add rule.

We'll then want to set the branch name pattern to *, which means all branches, check the Require status checks to pass before merging option, then select all of our different status checks that we'd like to require to pass before merging.

Finally, hit Create at the bottom of the page.

And once you navigate back to the pull request, you'll notice that the messaging is a bit different and states that we need our statuses to pass before we can merge.

Note: as an administrator of a repository, you'll still be able to merge, so this technically only prevents non-administrators from merging. But will give you increased messaging if the tests fail.

And with that, we have a new Github Action that runs our tests and prevents pull requests from merging if they fail.

Follow along with the pull request!

Note: we won't be merging that pull request before continuing to Part 2.

Part 2: Post new pull requests to Slack

Now that we're preventing merge requests if they're failing, we want to post a message to our Slack workspace whenever a new pull request is opened up. This will help us keep tabs on our repos right in Slack.

For this part of the guide, you'll need a Slack workspace that you have permissions to create a new developer app with and the ability to create a new channel for the bot user that will be associated with that app.

Step 1: Setting up Slack

There are a few things we're going to walk through as we set up Slack for our workflow:

  • Create a new app for our workspace
  • Assign our bot permissions
  • Install our bot to our workspace
  • Invite our new bot to our channel

To get started, we'll create a new app. Head over to the Slack API Apps dashboard. If you already haven't, log in to your Slack account with the Workspace you'd like to set this up with.

Now, click Create New App where you'll be prompted to put in a name and select a workspace you want this app to be created for. I'm going to call my app "Gitbot" as the name, but you can choose whatever makes sense for you. Then click Create App.

Once created, navigate to the App Home link in the left sidebar. In order to use our bot, we need to assign it OAuth scopes so it has permissions to work in our channel, so select Review Scopes to Add on that page.

Scroll own and you'll see a Scopes section and under that a Bot Token section. Here, click Add an OAuth Scope. For our bot, we don't need a ton of permissions, so add the channels:join and chat:write scopes and we should be good to go.

Now that we have our scopes, let's add our bot to our workspace. Scroll up on that same page to the top and you'll see a button that says Install App to Workspace.

Once you click this, you'll be redirected to an authorization page. Here, you can see the scopes we selected for our bot. Next, click Allow.

At this point, our Slack bot is ready to go. At the top of the OAuth & Permissions page, you'll see a Bot User OAuth Access Token. This is what we'll use when setting up our workflow, so either copy and save this token or remember this location so you know how to find it later.

Note: this token is private - don't give this out, show it in a screencast, or let anyone see it!

Finally, we need to invite our Slack bot to our channel. If you open up your workspace, you can either use an existing channel or create a new channel for these notifications, but you'll want to enter the command /invite @[botname] which will invite our bot to our channel.

And once added, we're done with setting up Slack!

Create a Github Action to notify Slack

Our next step will be somewhat similar to when we created our first Github Action. We'll create a workflow file which we'll configure to send our notifications.

While we can use our code editors to do this by creating a file in the .github directory, I'm going to use the Github UI.

First, let's navigate back to our Actions tab in our repository. Once there, select New workflow.

This time, we're going to start the workflow manually instead of using a pre-made Action. Select set up a workflow yourself at the top.

Once the new page loads, you'll be dropped in to a new template where we can start working. Here's what our new workflow will look like:

name: Slack Notifications on: pull_request: branches: [ master ] jobs: notifySlack: runs-on: ubuntu-latest steps: - name: Notify slack env: SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }} uses: abinoda/[email protected] with: args: '{\"channel\":\"[Channel ID]\",\"blocks\":[{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Pull Request:* ${{ github.event.pull_request.title }}\"}},{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Who?:* ${{ github.event.pull_request.user.login }}\n*Request State:* ${{ github.event.pull_request.state }}\"}},{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"\"}}]}' 

So what's happening in the above?

  • name: we're setting a friendly name for our workflow
  • on: we want our workflow to trigger when there's a pull request is created that targets our master branch
  • jobs: we're creating a new job called notifySlack
  • jobs.notifySlack.runs-on: we want our job to run on a basic setup of the latest Unbuntu
  • jobs.notifySlack.steps: we really only have one step here - we're using a pre-existing Github Action called Slack Action and we're configuring it to publish a notification to our Slack

There are two points here we'll need to pay attention to, the env.SLACK_BOT_TOKEN and the with.args.

In order for Github to communicate with Slack, we'll need a token. This is what we're setting in env.SLACK_BOT_TOKEN. We generated this token in the first step. Now that we'll be using this in our workflow configuration, we'll need to add it as a Git Secret in our project.

The  with.args property is what we use to configure the payload to the Slack API that includes the channel ID (channel) and our actual message (blocks).

The payload in the arguments is stringified and escaped. For example, when expanded it looks like this:

{ "channel": "[Channel ID]", "blocks": [{ "type": "section", "text": { "type": "mrkdwn", "text": "*Pull Request:* ${{ github.event.pull_request.title }}" } }, { "type": "section", "text": { "type": "mrkdwn", "text": "*Who?:*n${{ github.event.pull_request.user.login }}n*State:*n${{ github.event.pull_request.state }}" } }, { "type": "section", "text": { "type": "mrkdwn", "text": "" } }] } 

Note: this is just to show what the content looks like, we need to use the original file with the stringified and escaped argument.

Back to our configuration file, the first thing we set is our channel ID. To find our channel ID, you'll need to use the Slack web interface. Once you open Slack in your browser, you want to find your channel ID in the URL:

//app.slack.com/client/[workspace ID]/[channel ID] 

With that channel ID, you can modify our workflow configuration and replace [Channel ID] with that ID:

with: args: '{\"channel\":\"C014RMKG6H2\",... 

The rest of the arguments property is how we set up our message. It includes variables from the Github event that we use to customize our message.

We won't go into tweaking that here, as what we already have will send a basic pull request message, but you can test out and build your own payload with Slack's Block Kit Builder.

Follow along with the commit!

Test out our Slack workflow

So now we have our workflow configured with our Slack app, finally we're ready to use our bot!

For this part, all we need to do is create a new pull request with any change we want. To test this out, I simply created a new branch where I added a sentence to the README.md file.

Once you create that pull request, similar to our tests workflow, Github will run our Slack workflow! You can see this running in the Actions tab just like before.

As long as you set everything up correctly, once the workflow runs, you should now have a new message in Slack from your new bot.

Note: we won't be merging that pull request in.

What else can we do?

Customize your Slack notifications

The message I put together is simple. It tells us who created the pull request and gives us a link to it.

To customize the formatting and messaging, you can use the Github Block Kit Builder to create your own.

If you'd like to include additional details like the variables I used for the pull request, you can make use of Github's available contexts. This lets you pull information about the environment and the job to customize your message.

I couldn't seem to find any sample payloads, so here's an example of a sample github context payload you would expect in the event.

Sample github context

Περισσότερες ενέργειες Github

Με την ικανότητά μας να δημιουργούμε νέες προσαρμοσμένες ροές εργασίας, δεν μπορούμε να αυτοματοποιήσουμε πολλά. Το Github διαθέτει ακόμη και μια αγορά όπου μπορείτε να περιηγηθείτε σε ένα.

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

Εγγραφείτε στη συνομιλία!

. @ github Οι ενέργειες είναι ένας καταπληκτικός τρόπος αυτοματοποίησης της ροής εργασιών ανάπτυξης;

Μπορείτε να κάνετε πράγματα όπως αυτοματοποίηση δοκιμών και αποστολή ειδοποιήσεων στο @slack! ;

Εδώ σας καθοδηγώ ποιες είναι οι Ενέργειες και πώς μπορείτε να τις χρησιμοποιήσετε με το έργο σας

? // t.co/CNDIsNXbhm

- Colby Fayock (@colbyfayock) 3 Ιουνίου 2020

Για ποιο λόγο χρησιμοποιείτε τις ενέργειες Github;

Μοιραστείτε μαζί μου στο Twitter!

Follow me for more Javascript, UX, and other interesting things!

  • ; Ακολούθησέ με στο τουίτερ
  • ; ️ Εγγραφείτε στο Youtube μου
  • ✉️ Εγγραφείτε στο Newsletter μου