preface

Speaking of automation, in both the company and our personal project, can use or write some tools to help us to deal with trivial repetitive work, in order to save time to promote efficiency, especially we do front-end development involves such as building, deploying, and unit test these items repeat in the development workflow, This article is about using GitHub’s Actions to automate our front-end publishing.

Github Actions

What are the Actions

My personal understanding is that tasks can be triggered under certain conditions, using a task (Action) can be formed into our workflow, students who want to introduce the definition in more detail can go to the official Action definition, to help get more information, here is not handling

Benefits of using Actions

There are many front-end automation solutions, so what’s the appeal of GitHub’s Actions? In my opinion, Action has the following three highlights in front end automation publishing:

  • For free, actions can be tied to the Repo on GitHub (as shown below) right out of the box: this means that we don’t need to provide a machine to run tasks, or to hook up the flow of tasks, but simply learn the rules and get the project running. Most of us feel that A tool is troublesome because the steps are tedious. If we want to achieve function A, we still need to do B/C/D operations. At this time, we either give up or switch to simpler tools

  • Task plug-in, continue to enrich the plug-in open source market: Thanks to Github’s Actions specification, which allows us to use Actions based on known rules, this makes it easier to assemble and reuse Actions. Many good developers, after creating a workflow, Add your own Actions to GitHub’s Actions marketplace, so that you don’t need to develop your own regular workflow and use someone else’s Actions. In the author’s practice, the front-end construction and deployment workflow is realized by the combination of various existing Actions.
  • Integration with GitHub allows you to avoid the additional mental burden of using third-party tools like Travis. You can view CI/CD directly on GitHub.

Of course, there are many other benefits of Actions that you need to try out for yourself, at least those who have used Actions say 😬

Actions practices in business scenarios

Analysis of the source

Nebula Graph is an open source distributed graphics database (Nebula Graph: github.com/vesoft-inc/…) The project is managed by GitHub, so it is natural to use Actions provided by GitHub for free to complete our daily continuous integration workflow, and the front-end business is no exception.

For example, I created an official website dedicated to Nebula Graph. In addition to the developers who modify the site’s theme templates as required, the site’s built-in blog content is managed by the operations students, who update the content frequently. Almost every day the operations students post a technical blog post. In order to make the action of updating content completely independent of the developer, the site implements real-time deployment of updates, which requires the automation of the publishing process, which is one of the main scenarios for our front-end daily use of Github Actions.

Actions Quick start

Using Actions is easy, as long as your Repo source is associated with GitHub, then follow these steps to automate your front-end deployment.

In the root directory of the Repo, create a.github/workflows/ folder to store the description files of the workflows. A project can have multiple workflows.

Then, in the created.github/workflows/ directory, create a file describing the workflow with the.yml extension and name it, for example, publish.yml.

Next, refer to GitHub workflow description rules for task Actions configuration, details can be seen in the official document, of course, feel that the document is long, you can find a simple example on the Internet directly copy and try, under the personal test will soon be able to understand the Actions configuration routine.

The following is a summary of our own configuration to implement automatic publishing workflow on the official website, with a few notes to help you understand:

name:
on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # Here, each name corresponds to an Action. The specific execution logic has been encapsulated by the provider and exposed to the user only what the user needs to care about and configure
    Get the latest code from master
    - name: Checkout Github Action
      uses: actions/checkout@master
    
    # Our site was built using Hugo framework, here is the download environment
    - name: Setup Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: '0.65.3'
    
    To deploy resources to the cloud server, download a tool for SSH data transfer here
    - name: Setup sshpass
      run: sudo apt-get install sshpass

    Build front-end resources
    - name: Build
      run: hugo --minify -d nebula-website

    # deployment
    - name: Deploy
      uses: garygrossgarten/github-action-scp@release
      with:
          local: nebula-website
          remote: /home/vesoft/nebula-website
          Do not expose the information in this file because the REPO is likely to be public for all to see
          # ${{... }} protects private information from being seen by applying the corresponding serets key that you configured in the corresponding project Settings
          host: The ${{ secrets.HOST }}
          username: vesoft
          password: The ${{ secrets.PASSWORD }}
          concurrency: 20
Copy the code

Finally, it is necessary to submit corresponding changes to push the branch to the remote end, and the corresponding operation can be triggered as long as it conforms to the trigger rules defined in the workflow. For example, in my practice, only master code changes are allowed in the official website.

Complete the above steps to get your workflow running. For more details, see GitHub’s help documentation, which won’t be covered here.

Actions Precautions for use

Protection of private Information

.yML workflow configuration file, do not appear private information, such as: account number, password, IP and so on, you can put this kind of information into the Repo secrets Settings to add, and in the form of variable access ${{secrets. XXX}} in the configuration file.

Find the right Action

In configuring our workflow, it is not possible to personally develop every Action that needs to be used because our goal is to get things done quickly and efficiently. Instead, we go to the existing Actions market and use them directly.

For some sensitive Actions, such as uploading the server to the account and password of the Actions, it is best to check the specific implementation of the Actions before using, not only to predict whether there are risks, but also to satisfy the curiosity to understand the corresponding Actions specification and implementation mechanism. Help yourself next time to develop Actions to do technical accumulation.

Use your imagination

According to the actual needs, our workflow may have various needs. For example, when I started to use GitHub Actions, I needed to connect to VPN to access the development server. At first, I didn’t understand how to connect and I was afraid that it would be difficult to get it. After slowly finding the corresponding VPN command tool to do experiments and understand the call process, I quickly realized the desired effect.

As long as the demand is reasonable, you will not be the only one to encounter it, and there are two corresponding solutions. One is lucky to have ready-made Actions for you to use, and the other is to use scripts to describe the trouble points. In short, you should have imagination

Consider the performance of the free Runner

Runner is the environment to execute the configuration workflow, which is provided to users for free by GitHub. Of course, the large probability of free means that the performance capacity is limited. For the workflow of some large projects, sometimes the free runner runs slowly and does not meet the needs. A project as large as Nebula, for example, provides its own Runner environment. Without going into detail here, see the Official Self-Hosted Runners guide for those interested.

Summary of Actions practices

That’s what I’ve learned from using GitHub Actions in my daily front-end development. There are many different types of tasks that Actions can accomplish, such as continuous integration.

Through the workflow of the project, we can avoid repeating trivial work from all aspects and focus more on the realization of logic itself, which I think is the most desired state for engineers. We hope you’ve found this brief introduction helpful, and welcome to our Nebula open Source graphics database at 🤝

A: Hi, I am Jerry, a Nebula Graph front-end engineer with a background in software development and engineering for the Nebula Graph. I hope you can help with the Nebula Graph development experience

The appendix

  • Nebula Graph: An open source distributed Graph database
  • GitHub:github.com/vesoft-inc/…
  • Nebula graph. IO /cn/posts/
  • Weibo: weibo.com/nebulagraph