|
1 |
| -# github-actions-playground |
2 |
| -This repository is used as a playground to learn and mess with github actions. |
| 1 | +# Github Actions Playground |
3 | 2 |
|
4 |
| -## Notes |
| 3 | +In this repository you can find templates and examples of some github actions workflows that I use in my own projects. |
| 4 | +They are mainly focused around Typescript and React Native projects, because that's what I work with most of the time. |
5 | 5 |
|
6 |
| -A basic workflow is configured as follows: |
| 6 | +Feel free to copy them and use them in your own projects. |
7 | 7 |
|
8 |
| -```yaml |
| 8 | +## Contributing |
9 | 9 |
|
10 |
| -name: CI |
| 10 | +Contributions are welcome! If you have a workflow that you think is useful and you want to share it, feel free to open a |
| 11 | +pull request. |
11 | 12 |
|
12 |
| -on: [push] |
| 13 | +## Workflows |
13 | 14 |
|
14 |
| -jobs: |
15 |
| - build: |
16 |
| - name: Build |
17 |
| - runs-on: ubuntu-latest |
| 15 | +### Release with [release-it](https://github.com/release-it/release-it) |
18 | 16 |
|
19 |
| - steps: |
20 |
| - - name: SayHi |
21 |
| - run: echo "Hello, ${{ github.actor }}" |
| 17 | +This workflow is triggered manually and can bypass the ruleset that blocks any push to the main branch. It does it by |
| 18 | +using a Github App that has been added to the bypass list in the branch protection rules. |
| 19 | +Take a look at the [release-it-setup](./docs/release-it-setup.md) document to see how to set it up and an alternative |
| 20 | +approach to the bypass procedure. |
22 | 21 |
|
23 |
| -``` |
| 22 | +### Pass artifacts to next jobs |
24 | 23 |
|
25 |
| -Each job runs in a fresh instance of the virtual environment, this means that we need to checkout the branch and install |
26 |
| -the dependencies in each job; |
| 24 | +This workflow shows how to pass artifacts from one job to another. |
| 25 | +Take a look at the [pass-artifacts-to-next-job](./docs/pass-artifacts-to-next-jobs.md) document to see how to set it up. |
27 | 26 |
|
28 |
| -Continuos Integration (CI): is the practice of automating the integration of code changes from multiple contributors |
29 |
| -into a single software project. The CI process is comprised of automatic tools that assert the new code’s correctness |
30 |
| -before integration. This means that you can set up github actions to run tests, linters, etc. on each push to the |
31 |
| -repository or on a pull request. |
| 27 | +## Useful links |
| 28 | + |
| 29 | +- [Github Actions Documentation](https://docs.github.com/en/actions) |
32 | 30 |
|
33 |
| -Continuous Deployment (CD): is the practice of automating the deployment of code changes to a production environment. |
34 |
| -This means that you can set up github actions to deploy your code to a server, a cloud provider, etc. once you are |
35 |
| -ready to release a new version of your software. |
36 | 31 |
|
37 |
| -By default, github actions have got the GITHUB_TOKEN secret, which is a token that allows the action to interact with the |
38 |
| -github API. This token is automatically created by github and is available to all actions. You can use this token to |
39 |
| -create issues, pull requests, etc. from your actions. |
40 |
| -If you want to push to the repository tho, you need to update the permissions of the token and you can do it right in |
41 |
| -the worflow file using the `permissions` key. |
0 commit comments