|
1 |
| -# github-actions-demo |
| 1 | +# Instructor Demo: Configuring GitHub Actions |
| 2 | + |
| 3 | +At this point in the course, you are well aware that GitHub is a very powerful tool for collaborating with multiple users on the same project. Collaboration inevitably will cause some conflicts whether that be within the code itself or with your overall workflow. On occasion some errors will slip past a local linter and make their way into pull requests. Wouldn't it be nice to automate something like linting before each pull request? |
| 4 | + |
| 5 | +GitHub Actions is a great solution to this problem. For example, you could create a GitHub action to automatically run a linter against every pull request to ensure the code meets your agreed upon standards. Today, we are going to create such an action. |
| 6 | + |
| 7 | +* Before we begin, check out the [Introduction to GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions) to get a grasp on some of the core concepts. |
| 8 | + |
| 9 | +## Initial Project Setup |
| 10 | + |
| 11 | +TODO: this definitely doesn't work |
| 12 | +To begin, start by forking the following repository [GitHub Actions Demo](https://github.com/coding-boot-camp/github-actions-demo). Once you have forked this repository you should then clone the forked repository to your local machine. |
| 13 | + |
| 14 | +## Create the Workflow |
| 15 | + |
| 16 | +Now that we have some code locally, let's create the workflow that will contain the actions we want to preform after each pull request. |
| 17 | + |
| 18 | +1. In your terminal create a new directory called `.github`. GitHub will automatically look for this directory when it's pushed to your repository. |
| 19 | + |
| 20 | +2. Create a `workflows` directory inside `.github`. |
| 21 | + |
| 22 | +3. Finally, create a `main.yml` file inside your `workflows` directory |
| 23 | + |
| 24 | +The folder structure should look something like this: |
| 25 | + |
| 26 | +```md |
| 27 | +.github |
| 28 | +└── workflows |
| 29 | + └── main.yml |
| 30 | +``` |
| 31 | + |
| 32 | +## Actions |
| 33 | + |
| 34 | +Our actions will be defined inside of our `main.yml` file. To begin, let's open up `main.yml` in our code editor. YAML is a recursive acronym that stands for "YAML Ain't Markup Language". YAML is human-readable syntax for data that is being stored or transmitted. |
| 35 | + |
| 36 | +* Note that the first part of this file simply gives a name to our workflow. The `on` portion specifies what should trigger the workflow. We also want our actions to run whenever someone creates a pull request to the `develop`, or `staging` branches. |
| 37 | + |
| 38 | +* Next we specify the `jobs` that can run sequentially or in parallel. We are specifying that we want our job `test` to run on a container that uses Ubuntu as it's operating system. This container will be spun up by GitHub when our workflow is invoked. |
| 39 | + |
| 40 | +* The `steps` section contains what actions or tasks we want to run on our container. In our case we are checking out the branch, using node v20, installing dependencies, and finally running our `eslint` script. |
| 41 | + |
| 42 | + ```yml |
| 43 | + # Name of workflow |
| 44 | + name: Lint workflow |
| 45 | + |
| 46 | + # Trigger workflow on all pull requests |
| 47 | + on: |
| 48 | + pull_request: |
| 49 | + branches: |
| 50 | + - develop |
| 51 | + - staging |
| 52 | + |
| 53 | + # Jobs to carry out |
| 54 | + jobs: |
| 55 | + test: |
| 56 | + # Operating system to run job on |
| 57 | + runs-on: ubuntu-latest |
| 58 | + |
| 59 | + # Steps in job |
| 60 | + steps: |
| 61 | + # Get code from repo |
| 62 | + - name: Checkout code |
| 63 | + uses: actions/checkout@v1 |
| 64 | + |
| 65 | + - name: Use Node.js 21.x |
| 66 | + uses: actions/setup-node@v1 |
| 67 | + with: |
| 68 | + node-version: 21.x |
| 69 | + |
| 70 | + # Install dependencies |
| 71 | + - name: 🧰 install deps |
| 72 | + run: npm install |
| 73 | + |
| 74 | + # Run lint |
| 75 | + - name: Run lint |
| 76 | + run: npm run lint |
| 77 | + ``` |
| 78 | +
|
| 79 | +* Save the content of the snippet above to your `main.yml` file. |
| 80 | + |
| 81 | +## Create a Pull Request |
| 82 | + |
| 83 | +Now it's time to give our linter something to complain about! We will make some changes in any component and then create a pull request. |
| 84 | + |
| 85 | +1. First let's make a new feature branch to create a pull request from: |
| 86 | + |
| 87 | + ```sh |
| 88 | + git checkout -b feat/linting-test |
| 89 | + ``` |
| 90 | + |
| 91 | +2. Add and commit your changes, then push them to our `feat/linting-test` branch |
| 92 | + |
| 93 | + ```sh |
| 94 | + git add . |
| 95 | + git commit -m "Creating a PR for testing" |
| 96 | + git push origin feat/linting-test |
| 97 | + ``` |
| 98 | + |
| 99 | +3. Head to GitHub and click "Create pull request" next to the yellow indicator for our recent change to `feat/linting-test`. |
| 100 | + |
| 101 | +  |
| 102 | + |
| 103 | +4. Click "Create pull request" and then click on "details". |
| 104 | + |
| 105 | +  |
| 106 | + |
| 107 | +5. In this view we can see the output of our workflow |
| 108 | + |
| 109 | +  |
| 110 | + |
| 111 | +6. The PR should be automatically marked as having failed checks, indicating the author needs to refactor some of the code. |
| 112 | + |
| 113 | +  |
| 114 | + |
| 115 | +## Conclusion |
| 116 | + |
| 117 | +Congratulations on gaining experience with GitHub Actions! This powerful feature can become part of your CI/CD pipeline, providing valuable automation and efficiency. While you might not use it for every project, it can be especially useful for group projects or large organizations. |
| 118 | + |
| 119 | +--- |
| 120 | +© 2025 edX Boot Camps LLC. Confidential and Proprietary. All Rights Reserved. |
0 commit comments