Discussion: Utilise GitHub actions to automate various processes

[xzilja]

Looking at some other issues here related to automating releases / enforcing certain checks it is clear that we will need some common ci solution for all of these.

I would usually go for circle, but have recently switched my personal projects to GitHub actions and thus far only limitation there was that Docker can't run macOS environment.

Otherwise, process is very simple and creating your own actions doesn't take much effort either.

Hence I thought about proposing this for repos within React Native Community (At least some of them that don't have CI yet?).

We could create new repository here that could house custom actions created by the community, so they are easily accessible to every maintainer as well ass have examples for different workflows, including main one that community might accept as a standard?

Utalising these will mean we can easily add things like Danger since we won't need to fiddle with github permission token generation (actions expose one as default secret), nor will we need to set up each repo on a third party ci service.

What do you guys think? If this is interesting it might be worth to enrol react-native-community into Github Actions Waiting list (if it is not there yet) https://github.com/features/actions

[pvinis]

Probot has a bunch of useful ones.

[xzilja]

@kelset I think we could move this issue to template repo now

[mikehardy]

Yeah this should probably move, but I will say I like some of the bots but I wouldn't implement functionality in them or we increase github lockin. I like bots that handle actual github interactions (issue preening and so on, or that simply respond to hooks by poking a separate distributed system like semver release) but to actually do things related to producing and distributing code makes me nervous.

[xzilja]

@mikehardy We can definitely start with just github actions like labeling issues based on file changes or checking that issues utilise predefined templates (kinda like in react-native repo).

I also thought of using actions for things like lint typecheck etc... since these won't make us locked into github per se, as they are just scripts inside package.json file and all we do in github actions is run them within docker image that has npm or yarn. Moving these commands to any other ci would be a trivial task, but in terms of benefits I think it will save a lot of time for heavy tasks like e2e / builds / releases on circle or any other ci service.

[kelset]

Uhm I actually think that there is a fair chance that the action files may be shared as the other health files (similar to the bots configurations btw). I'll ask around

[mikehardy]

My line of thinking for that specific example lint vs ci and triviality is more about cognitive load. If a project I'm working on uses CircleCI and I want to make sure I do a good PR, I look at the CI file and do what it does. If checks start splitting between different places then it's not declared in one spot and it's harder for me to PR with high quality

So then if I prefer a single source of check declarations, and CI is a must regardless, I lean towards all CI.

It's a preference though, not something to lose sleep over for me. And maybe github actions allow containers with nested virtualization so we can do all CI including e2e+emulators there without the CircleCI minutes limitations (did you know Travis has no open source limitations btw?) or something. Just to say - I might be missing something and change my preference in response