This repository contains various proofs of concept using a Github Actions through workflows 🤖
- Introdução ao Github Actions
- Como executar um script usando GitHub Actions
- Github Actions – variáveis de ambiente e secrets
- Como manipular outputs no GitHub Actions
- Workflows no GitHub Actions: como usar events e triggers
- Como manipular outputs no GitHub Actions
- Como usar imagens do Docker com workflows no Github Actions
- Como gerenciar artefatos nos workflows do Github Actions
- Como usar condicionais nos workflows do Github Actions
- 10 boas práticas e dicas para usar o GitHub Actions
- Quando usar Reusable Workflow ou Composite Action no GitHub Actions?
name: Github action workflow name
on:
push: # Run this workflow every time a new commit pushed to the repository
pull_request: # Run this workflow every time a new pull request is opened to the repository
scheduled: # Run this workflow as a cron job
- cron: "0 0 * * MON-FRI"
workflow_dispatch: # Run this workflow on demand (manually)
jobs: # All workflows need at list one job
job-key: #First job
name: Job Name
runs-on: ubuntu-latest # Set the type of machine the workflow will run on
steps: # Each job can be divided in many steps
- name: Checkout code # Step name
uses: actions/checkout@v2 # Action used on the step
- name: Run Super-Linter # Another step name
uses: github/super-linter@v3 # Action used on the step
env: # Environment variables used on the step
DEFAULT_BRANCH: main
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Run specific commands # Another step name
run: |
ls -lha
echo "This is a shell command"
This workflow uses CRON to run some basic commands.
This workflow uses CRON to run some basic commands using repository secrets.
This workflow uses CRON to execute a specific script run.py located on the repository.
This workflow uses CRON to dispatch an event to the ritchie-formulas-scheduler-demo repository.
This workflow uses CRON with a docker container where Ritchie CLI and Golang are installed, then check Ritchie CLI and Golang versions through commands.
This workflow uses CRON and a docker image foundeo/minibox:latest
. It also specify an entrypoint
(the command to run inside the container) and args
(command line arguments to pass to the command specified in entrypoint). It is possible to omit the entrypoint
if the container already species the entrypoint you want to use.
This workflow will run an Action each time a PUSH
event occurs on the repository. This specific action runs a Ritchie CLI formula.
This workflow illustrates how to set outputs in a job to use them on another job. This specific workflow prints Hello-World
.
This workflow illustrates how to pass data between jobs in the same workflow. For more information, see the actions/upload-artifact and download-artifact actions. The full math operation performed in this workflow example is (3 + 7) x 9 = 90
.
This workflow illustrates how to use environment
variables from the whole workflow, a specific job, or a specific step, as well as for an environment secret.
This workflow illustrates how to use input
variables on a workflow_dispatch
event.
This workflow illustrates how to run a workflow once another specific one has been completed (with success or failure).
This workflow uses CRON to automatically create a Pull Request committing updated files.
This workflow illustrates how to automatically merge a Pull Request with a specific label automerge
.
This workflow only run when a push is made to the dev
branch.
Note that with this implementation, the workflow needs to be present on the specific branch as well (here dev
).
This workflow illustrates how to use conditional through the if
variable.
This workflow illustrates how to write an automatic comment on a new issue, without using action, through the github API.
This workflow illustrates how to trigger a workflow when specific files are updated by a push
or pull_request
event.
This workflow illustrates how use the checkout action to create a push event, updating a file and committing it to the branch.
This workflow illustrates how use cherry-pick to generate a new repository tag informing 3 inputs (reference tag
, new tag
, and commit hash
).
This workflow illustrates how use cherry-pick to generate a new release branch informing 3 inputs (reference tag
, new tag
, and commit hash
).
This workflow illustrates how to install tools not supported by the ubuntu runner using apt-get install
.
This workflow illustrates how to upload a release asset. Example
This workflow illustrates how to access various context variables on a workflow.
These workflows illustrate how to share datas between various workflows using artifacts.
This workflow illustrates how to create a new branch on another repository based on the current repository tag.
This workflow illustrates how to use outputs between jobs with the needs
context to check tags and manage them to perfom some operation according to their name.
This workflow illustrates how to create a new Pull Request based on a branch name after a push event.
This workflow illustrates how to add a comment on a new Pull Request based on the github actor name after a PR event.
This workflow illustrates how to call a webhook on each release extracting the release tag.
This workflow illustrates how to close a Pull Request automatically if it updates on file that shouldn't be modified.
This workflow illustrates how to perform a specific action when approving a Pull request if it contains a specific label.
This workflow illustrates how to implement a reusable workflow.
This workflow illustrates how to use and call a reusable workflow (cf workflow 33 above).
This workflow illustrates how to extract and use the user email and username from the commit using github config log commands.
This workflow illustrates how to use a local action
file in one (or multiple workflows) and extract its outputs to perform other operations.
This workflow illustrates how to use matrix as well as expressions with continue-on-error
and if
conditionnal fields.
This workflow illustrates how to get the related PR number to a push event.
PR event and Related PUSH event
This workflows illustrate how to extract the tag version when a specific branch is created (e.g: release-1.2.3
), and how to invoke another workflow through a disptach event sending this tag as input.
This workflow illustrates how to commit files from the current repo to another repo.
This workflow illustrates how to trigger a workflow on different event but NOT on tag.
This workflow illustrates how to check if a PR is opened from a FORK repository or not.
This workflow illustrates how to list all files from a specific extension (here, .yaml
or .yml
).
This workflow illustrates how to list all env variables set in the runner.
This workflow illustrates how to force a workflow failure if a condition isn't met.
This workflow illustrates how to wait for other workflows completion before executing some operation (using reusable workflows).
This workflow illustrates how to rename a file according to the github ref name
(branch or tag name).
This workflow illustrates how to simply create a tag in a job.
This workflow illustrates how to use concurrency to avoid the same workflow to run in parallel for different push to the same branch (for example to limit Github actions runner usage in private repo).
This workflow illustrates how to print secrets values on a workflow run. To harden the security of your github actions, have a look at this guide on the Github Official Documentation.
This workflow illustrates how to concatenate env
variables using the environment file.
This workflow illustrates how to use the permission
field at the workflow level. Giving the GITHUB_TOKEN a specific permission scope during the workflow execution.
These workflows illustrate how to create and read an issue body variable according to a specific issue template.
This workflow illustrates how to use outputs with reusable workflows.
This workflows illustrates how to use expressions when setting env variables ath the workflow level, according to the trigger event.
This workflows illustrates how to use step context, which contains detail about the execution of each step by default. Using the outcome
property of each step we can check the result of its execution.