But I would like to know what it get's us over what we already are using.

Better integration of permissions. Since Actions is built in GitHub, it is possible to use secret tokens without explicitly managing/setting them. Moreover, API calls are internal between GitHub services, so there is a smaller surface for potential attacks/leaks/issues.
- This is not used ATM. However, in the future I would suggest to deploy binaries of an example/demo project. This would allow to:
  - Have an example for users that want to have a feel of how a cobra CLI looks like.
  - Show developers an example of how to build, test and deploy an application based on cobra.
GNU/Linux, macOs and Windows platforms in the same service. Currently, GNU/Linux platforms are tested only.
- Moreover, Travis and CircleCI seem to be duplicated. I don't know what is the motivation for this. My porposal would be to deprecate both of them in favour of Actions.
- Startup time is much faster that Travis, and I'd say that much faster than CircleCI too.
Actions allow to have up to 20 workflows, where each workflow is a YAML file. Hence, having a single Action account is equivalent to having 20 Travis CI or CircleCI projects. This allows to have a set of tasks to be executed daily, others weekly, etc.
- Workflows can be filtered depending on which source files were modified. This allows for fine granularity.
Actions are not about bash/python/golang CI/CD only. There is a toolkit that allows complex custom tasks that interact with GitHub.
- For example, it is possible to have a task to automatically reply with a greeting comment to each issue opened by a new user. That's just a toy example.
- This example, extracts the code blocks in the first comment of an issue and executes them in a job.
  - The results can be uploaded as artifacts of the job/test, the log or some summary can be added to the issue (as a comment), etc.
  - I think this is especially useful for users to provide reproducible MWE that are automatically tested with latest master. At the same time, it allows maintainers to request issues to contain reproducible MWE, so it is possible to understand the context exactly.
- By the same token, as suggested in #959, it should be possible to parse the body of PRs to have them self-labelled by contributors. I.e., breaking changes could be explicitly marked without maintainers being required to manually add the label.

GitHub Actions #952

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions