This article introduces some of Github’s senior management. Our open source projects are currently maintained and developed on Github. So we use some of Github’s open capabilities to manage our projects to reduce the complexity of our development and maintenance processes.

probot

An application that automates and improves your workflow, extends GitHub with pre-built applications, and easily builds and shares your own applications.

Probot applications are easy to write, deploy, and share. Many of the most popular Probot applications are hosted, so you don’t have to deploy and manage anything. Here are some examples of builds using Probot:

  • Pull – Keep your branches up to date
  • Release Drafter – Draft your next Release notes when pull requests are merged into master
  • Semantic Pull Requests – Status check to ensure that your Pull Requests comply with regular submission specifications
  • Todo – Creates new problems from actionable comments in code
  • Work In Progress – Prevents merge pull requests with “WIP” In the title
  • Settings – Pull requests for repository Settings

The Probot application is essentially a Node.js module that exports a function, and the app argument is an instance of the Probot class. App.on listens for all GitHub triggered Webhook events and notifies you when anything interesting happens on GitHub that your app wants to know about

module.exports = app= > {
  app.on('issues.opened'.async context => {
    // A new issue is opened, what should we do?
  });
};
Copy the code

Generate a new project

npx create-probot-app my-demo
Copy the code

For other configurations, refer to the official documents

GitHub Actions

Lightweight automated deployment. GitHub provides pre-configured workflow templates that you can customize to create your own continuous integration workflow. GitHub parses the code and displays CI templates that might be appropriate for your repository.

Github also offers some open source portals that you can learn from.

workflow

Workflow, the continuous integration of a running process, is called a workflow. A workflow trigger is an event that causes a workflow to run. These events can be:

  • Events that occur in your working stream repository
  • Repository_dispatch occurs outside of GitHub and triggers the Repository_dispatch event on GitHub
  • The scheduled time
  • manual

├─ Name Name of the workflow ├─ Name of the event that triggered the workflow ├─ Jobs The main body of the workflow, a workflow consists of a job or a number of tasks, indicating a continuous integration of the run │ │ ├─ job_id Each task must have an ID, │ │ ├─ runs-on Virtual environment for the task to run. │ │ ├─ Steps Each task consists of several steps │ │ │ ├─ name │ │ │ ├─ run The command to run or action │ │ ├─ env Environment variables │ │ ├─ env ├── uses Selects part of the operation to run in the task steps. The actions used by the step can be one or more actions

name: scp files
on: [push]
jobs:

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
      uses: actions/checkout@v2    
    - name: Upload Files
      uses: siva1024/scp-deployer@latest
      with:
        host: ${{ secrets.HOST }}
        username: ${{ secrets.USERNAME }}
        key: ${{ secrets.KEY }}
        source: "entrypoint.sh"
        target: "~/"
Copy the code

website

GitHub REST API

Create integration, retrieve data, and automate workflows, built using the GitHub REST API. In the process of using GitHub, we can call GitHub open interface for us to operate, basically used to provide, such as: operation, warehouse, pull, search and so on. Some functions require authentication, and we configure the authentication process through the official website.

Method of use

To create a personal token: setting –> Developer Settings –> OAuth Apps –> New OAuth App

OAuth app does not have Client secret. You need to click Generate a new Client secret to Generate it. After you Generate it, you should save it.

validation

Through the above operation, we filled ClientID and Client Secrets information into the link below for login and authorization

`https://github.com/login/oauth/authorize?client_id=*&redirect_uri=*`
Copy the code

Authorized after the success will jump to by redirect_uri specified address, and will add path behind the temporary code values, use this value to call POST https://github.com/login/oauth/access_token, Client_id, client_secret, code, access_token, github REST API, then add “Authorization” to the header: “Token” + access_token can be used normally

Development use

All API access is via HTTPS and from https://api.github.com. All data is sent and received in JSON format.

curl -I https://api.github.com/users/octocat/orgs

> HTTP/2 200
> Server: nginx
> Date: Fri, 12 Oct 2012 23:33:14 GMT
> Content-Type: application/json; charset=utf-8
> ETag: "a00049ba79152d03380c34652f2cb612"
> X-GitHub-Media-Type: github.v3
> x-ratelimit-limit: 5000
> x-ratelimit-remaining: 4987
> x-ratelimit-reset: 1350085394
> Content-Length: 5
> Cache-Control: max-age=0, private, must-revalidate
> X-Content-Type-Options: nosniff
Copy the code

Basic authentication

curl -u "username" https://api.github.com
Copy the code

OAuth2 token

curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com
Copy the code

OAuth2 Key/secret

curl -u my_client_id:my_client_secret 'https://api.github.com/user/repos'
Copy the code

Open interface links as follows: docs.github.com/cn/rest/ove…

GitHub Issues

Collect and deal with bugs and new features of products; Building product-centric communities; According to the issue, the weak link and future trend of the product can be located.

Users can consult using problems through issue, or query past issues to solve their own problems; Exchange experience with different users, maybe international friends; Communicate with maintainers and participate in product development.

However, the Issues submitted by operators are not very standardized, so it is difficult for developers to locate problems.

I have two solutions to change the situation:

By creating a problem template

  • To display the issue template in the root directory of the repository, enterissue_templateThe name of the
  • To make the issue template display in the repositorydocsIn the directory, type docs/ and followissue_templateThe name of the. For example,docs/issue_template.md
  • To store the file in a hidden directory, enter.github/, followed byissue_templateThe name of the. For example,.github/issue_template.md.
  • To create multiple issue templates and specify the template to populate the issue body using the template query parameter, enter.github/ISSUE_TEMPLATE/, followed by the issue template name
** What does this issue do? **(Briefly describe the changes)** What platform is this Issues? **(Choose at least one)- [ ] web/h5
-[] applet** This issue involves the following packages :**
- [ ] eslint
- [ ] stylelint
- [ ] commitlint
Copy the code

Through an external browser

Through the features of GitHub REST API, we did some verification and judgment before creating the issue, and created the issue after the verification was successful.

First we use the /search/issues interface to get issues, during the creation process to avoid repeated calls.

The interface for creating issues has not been developed, we can create it automatically by opening github create link

window.open(`https://github.com/xxx/xxx/issues/new?title=${title}&body=${body}${label}`)
Copy the code

Summary: GitHub has a lot more to do with it, so I’ll introduce it here and keep updating it later. The essence is to let developers save tedious steps, so that developers can use easily.