* add 3.1 to deprecated versions * rewrite img src to use azure blob storage in archive script Co-authored-by: rachmari <rachmari@users.noreply.github.com> * remove static files for ghes 3.1 * remove liquid conditionals and content for ghes 3.1 * remove outdated hardware reqs reusable * Fix liquid conditional uncaught by script * Close liquid conditionals missed by script * Apply @mattpollard's suggestions Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com> Co-authored-by: rachmari <rachmari@users.noreply.github.com> Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com>
6.5 KiB
Create an example workflow
{% data variables.product.prodname_actions %} uses YAML syntax to define the workflow. Each workflow is stored as a separate YAML file in your code repository, in a directory named .github/workflows.
You can create an example workflow in your repository that automatically triggers a series of commands whenever code is pushed. In this workflow, {% data variables.product.prodname_actions %} checks out the pushed code, installs the bats testing framework, and runs a basic command to output the bats version: bats -v.
-
In your repository, create the
.github/workflows/directory to store your workflow files. -
In the
.github/workflows/directory, create a new file calledlearn-github-actions.ymland add the following code.name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: ubuntu-latest steps: - uses: {% data reusables.actions.action-checkout %} - uses: {% data reusables.actions.action-setup-node %} with: node-version: '14' - run: npm install -g bats - run: bats -v -
Commit these changes and push them to your {% data variables.product.prodname_dotcom %} repository.
Your new {% data variables.product.prodname_actions %} workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository. To see the details about a workflow's execution history, see "Viewing the activity for a workflow run."
Understanding the workflow file
To help you understand how YAML syntax is used to create a workflow file, this section explains each line of the introduction's example:
|
Optional - The name of the workflow as it will appear in the Actions tab of the {% data variables.product.prodname_dotcom %} repository. |
|
Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for {% data variables.product.prodname_actions %}."
|
|
Groups together all the jobs that run in the learn-github-actions workflow.
|
|
Defines a job named check-bats-version. The child keys will define properties of the job.
|
|
Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Workflow syntax for {% data variables.product.prodname_actions %}." |
|
Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.
|
|
The uses keyword specifies that this step will run v3 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will run against the repository's code.
|
|
This step uses the {% data reusables.actions.action-setup-node %} action to install the specified version of the Node.js (this example uses v14). This puts both the node and npm commands in your PATH.
|
|
The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.
|
|
Finally, you'll run the bats command with a parameter that outputs the software version.
|
Visualizing the workflow file
In this diagram, you can see the workflow file you just created and how the {% data variables.product.prodname_actions %} components are organized in a hierarchy. Each step executes a single action or shell script. Steps 1 and 2 run actions, while steps 3 and 4 run shell scripts. To find more prebuilt actions for your workflows, see "Finding and customizing actions."
Viewing the activity for a workflow run
When your workflow is triggered, a workflow run is created that executes the workflow. After a workflow run has started, you can see a visualization graph of the run's progress and view each step's activity on {% data variables.product.prodname_dotcom %}.
{% data reusables.repositories.navigate-to-repo %}





