Set up continous integration

[zbraniecki]

The way I run CI for my projects is via Travis.
I have an account there, connected my project to it and set up a .travis.yml file.

Here's the view of fluent-rs CI: https://travis-ci.org/github/projectfluent/fluent-rs

I'm not sure what other options exist beyond Travis and if we want to use it. @echeran ?

[sffc]

I've heard (don't exactly remember where) that for a free CI solution, GitHub Actions is compatible with Travis and should be used for newer projects.

For a paid solution, we can do anything that GCP supports.

[sffc]

Explanation of labels:

"R-needs-more-info" is a resolution for closed issues. Maybe we should have a similar label for open issues, like "discuss".

For the type, I think "T-core" is most appropriate here, since CI is a core feature of the project.

[zbraniecki]

I've never used github actions, but would be open to! @echeran do you want to try setting this up?

[echeran]

Yeah, let's try out Travis for starters. It seems like an easy and prevalent solution for open source, and may integrate with fancier things like Coveralls like you were mentioning. We can iterate from there.

[sffc]

Here's where Node.js moved from Travis to GitHub Actions:

nodejs/node#32450

A quick Google search finds a number of other people jumping on this bandwagon:

https://www.google.com/search?q=travis+vs+github+actions

The original motivation is that Travis CI was acquired, and there was speculation that the new owners intend to "milk" Travis CI and discontinue feature development. Here is a discussion on this subject and the new owner's official response to that speculation:

https://travis-ci.community/t/after-idera-future-development-and-support-plans/2474

[sffc]

To be clear, I have no strong opinion between Travis CI and GitHub Actions. I like Travis CI and would be okay if we used it. I'm just providing some context of a trend I've seen.

@srl295

[srl295]

I have nothing against travis. (i.e. no reason not to use it.) In fact, it's what I use extensively internally, and I did a lot of the tooling for setting up icu and cldr's travis config. The travis-ci.org can get backed up and take a while to start queues, but I think that's a lot better than it used to be.

Github actions have some advantages, I think:

• better integration (unsurprisingly) in the UI
• I like the separate workflow concept: parallel things can be in separate action files, not all in one .travis.yml
• modularity, being able to import from other actions. This means fewer helper-scripts checked into the main repo and/or waiting for core support for something.

OTOH if, say, fluent-rs is already using travis, there may be some advantage to getting up and running copying what's already been setup.

https://github.com/projectfluent/fluent-rs/blob/master/.travis.yml looks nicely done. So I'd say: I'd lean towards actions, but in the end go for expediency. If @zbraniecki is implementing and wants to use travis, no reason not to

one thing to consider is how the monorepo structure will look with the build. Just have a list of components and build them? Have a parallel build? I don't know what build times look like here.