YouTip

GitHub Actions GitHub Actions is an automation platform built into GitHub that allows you to define and run automation workflows directly in your code repository without relying on any external CI/CD tools. Common uses include: automatically running tests after code push, automatically deploying to server after merging PR, scheduled data scraping scripts, etc. !(#) GitHub Actions is **completely free for public repositories**, and private repositories have 2,000 minutes of free usage per month. * * * ## Core Concepts Before writing configuration files, you need to understand the following core concepts. Their relationships are as follows: Repository└── Workflow ← one .yml file = one Workflow ├── Event ← what triggers this Workflow, such as push, PR └── Job × N ← a Workflow can contain multiple parallel or serial Jobs ├── Runner ← the server that executes Jobs, such as ubuntu-latest └── Step × N ← a series of operations executed sequentially within a Job ├── Action ← reusable packaged operations, such as actions/checkout └── Run ← directly execute Shell commands | Concept | Description | Analogy | | --- | --- | --- | | **Workflow** | The entire automation process, defined by a `.yml` file, stored in the `.github/workflows/` directory | A complete work plan | | **Event** | The condition that triggers the Workflow to run, such as code push, PR creation, scheduled tasks, etc. | The trigger condition for the plan | | **Job** | An independent task unit in the Workflow, each Job runs on a separate virtual machine, multiple Jobs run in parallel by default | A chapter in the plan | | **Step** | The smallest operation unit executed sequentially within a Job, can be a Shell command or an Action | Each specific step in a chapter | | **Action** | Reusable packaged operations, from GitHub official, third-party, or self-written, referenced via `uses` | Ready-made tool templates | | **Runner** | The server that executes Jobs, GitHub provides three hosted environments: Ubuntu, Windows, and macOS | The staff executing the plan | * * * ## Creating Your First Workflow ### 1. Directory Structure All Workflow files must be stored in the `.github/workflows/` folder at the repository root, with filenames ending in `.yml` or `.yaml`. The filename can be customized: your-repo/├── .github/│ └── workflows/│ ├── ci.yml ← Continuous integration process (e.g., running tests)│ ├── deploy.yml ← Deployment process│ └── scheduled.yml ← Scheduled tasks├── src/├── package.json └── README.md A repository can have multiple Workflow files, they are independent of each other and are triggered by their respective defined events. ### 2. The Simplest Workflow Below is a basic example: print "Hello, GitHub Actions!" every time code is pushed to the repository: ## Example # .github/workflows/hello.yml name: Hello World # Workflow name, displayed on the GitHub Actions page on: push # Trigger condition: triggered when code is pushed to any branch jobs: # Define all Jobs say-hello: # Job ID (custom name, must be unique within the same Workflow) name: Print Greeting # Job display name (optional, Job ID is shown if not filled) runs-on: ubuntu-latest # Specify runtime environment: use GitHub's latest Ubuntu virtual machine steps: # All steps under this Job, executed in order - name: Print Message # Step name (optional, used to identify this step in logs) run: echo "Hello, GitHub Actions！"# run: directly execute Shell command > YAML files are very sensitive to indentation and must use **spaces** for indentation, not Tab keys. It is recommended to use VS Code with the YAML plugin installed, which can detect format errors in real-time. * * * ## Trigger Events (on) The `on` field defines which events trigger this Workflow. It can be a single event or a combination of multiple events. ### 1. Common Trigger Events | Event | Trigger Time | Common Uses | | --- | --- | --- | | `push` | When code is pushed to the repository | Run tests, code checks | | `pull_request` | When a Pull Request is created or updated | Auto review, tests before PR merge | | `schedule` | Triggered periodically according to Cron expression | Scheduled backups, scheduled data scraping | | `workflow_dispatch` | Manually triggered on GitHub web page | On-demand deployment, manual script execution | | `release` | When a new version is released (Release created) | Auto packaging, release to production | | `workflow_call` | When called by other Workflows | Reuse common flows (e.g., common test flow) | ### 2. Specify Branch or Path Filtering ## Example on: push: branches: - main # Only trigger when pushing to main branch - develop # Or when pushing to develop branch - 'release/**' # Or when pushing to any branch starting with release (** matches any character) paths: - 'src/**' # Further filter: only trigger when files in src/ directory change - 'package.json' # Or when package.json file changes # The two are "OR" relationship, trigger if either is satisfied pull_request: branches: - main # Only trigger on PRs with main as target branch (i.e., PRs to be merged into main) types: - opened # When PR is created - synchronize # When new commits are pushed to PR - reopened # When PR is reopened ### 3. Scheduled Trigger (schedule) Use standard Cron expression to define execution time, timezone is UTC (Beijing time = UTC+8, need to convert): ## Example on: schedule: # Cron format: minute hour day month weekday - cron: '0 2 * * *' # Execute once daily at UTC 02:00 (i.e., Beijing time 10:00) - cron: '0 9 * * 1' # Execute every Monday at UTC 09:00 (i.e., Beijing time 17:00) - cron: '*/30 * * * *' # Execute every 30 minutes # Common Cron expression quick reference: # '0 0 * * *' Daily at midnight (UTC 00:00) # '0 * * * *' Every hour at the hour # '0 0 * * 0' Every Sunday at midnight # '0 0 1 * *' First day of every month at midnight ### 4. Manual Trigger (workflow_dispatch) `workflow_dispatch` allows manually clicking a button to start the Workflow on the GitHub web page's Actions tab. You can also define input parameters: ## Example on: workflow_dispatch: inputs: environment: # Input parameter name (can be referenced in steps via ${{ inputs.environment }}) description: 'Deployment Target Environment' # Parameter description, displayed in the manual trigger form required: true # Whether it's required default: 'staging' # Default value type: choice # Parameter type: choice (dropdown) options: - staging # Optional value - production run_tests: description: 'Whether to run tests' required: false type: boolean # Parameter type: boolean (checkbox) default: true jobs: deploy: runs-on: ubuntu-latest steps: - name: Display Deployment Parameters run: | echo "Target Environment: ${{ inputs.environment }}" echo "Run Tests: ${{ inputs.run_tests }}" * * * ## Jobs and Steps in Detail ### 1. Basic Job Structure ## Example jobs: build: # Job ID, must be unique within the same Workflow name: