Cobra: GitHub Actions

[umarcor]

It seems that GitHub Actions (beta) is enabled for @spf13's repos, so it works here: https://github.com/spf13/cobra/actions

I think we should migrate from Travis CI (and maybe circleci) to GitHub Actions, and add macOS and Windows jobs too.

Ref #907

[jharshman]

I have no problem piloting Github Actions. But I would like to know what it get's us over what we already are using.

[umarcor]

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[bot]]

This issue is being marked as stale due to a long period of inactivity

[umarcor]

Not stale.

[umarcor]

Ref #968 #1074 #1075

[xchapter7x]

it seems like from a visibility and ease of maintenance perspective, keeping everything under github would allow for cleaner & more clearly defined user access.

Echoing a point from above, the integrations all being here might make it easier for contributors (maintainers and non-maintainers alike) to more easily help on tech-debt/workflow type chores as well as new feature development.

My only question is one of this internal workflow enhancements WRT overall project priority. Thats more a @jharshman call.

[jharshman]

Our current experimentation with Github Actions haven't actually worked so far. So you see where I am reluctant to adopt this further.

[umarcor]

I do understand that. However, unlike the actions that you already merged, #968 is absolutely harmless. This is because #968 is directly equivalent (just a translation) of the current Travis workflow. Conversely, the actions contributed in #1074 and #1075 do make permanent modifications in the repo, and are based on not-yet-well-developed resources. I'm sure that using GHA for the known workflows will allow you to get a better feel.

[jharshman]

1074 and #1075 do make permanent modifications in the repo

No these were less than low impact and do not make any permanent modifications or changes.

@umarcor I am all for using GH actions, but as of right now - I am not sold on the direction or utility. However, the other maintainers and myself will discuss it in planning.

[umarcor]

Ref #1097 #1112

[umarcor]

From https://github.com/spf13/cobra/pull/968#issuecomment-626648821:

(...) workflows contributed by PRs are now executed and shown both here and in https://github.com/spf13/cobra/actions.

Hence, users willing to use GHA can cherry-pick the commit in this PR #968, regardless of the maintainers picking it.

[github-actions[bot]]

This issue is being marked as stale due to a long period of inactivity

[umarcor]

However, the other maintainers and myself will discuss it in planning

@jharshman, any update?

[umarcor]

Ref: #1044