Proposal to add Github CI

[still-flow]

As it turns out, Github has its own CI system as part of "Actions". I'll leave it up to zenorogue to decide whether it's needed or worth it, but here is a more or less direct port of the current Travis configuration. It's not quite the same, of course: the main build matrix is every configuration of
{MacOS, Ubuntu} x {GCC, clang} x {makefile, autotools, mymake} x {rogueviz, no rogueviz},
and emscripten build is separate from that matrix. This is just a simple configuration, of course it's up to discussion to decide what needs to be there and what doesn't. There is also a temporary hack disabling warnings->errors. I think that there exist ways to gather all warnings from a build without failing it, but I haven't looked into that yet.

Example result using the configuration from the commit.

One note to zenorogue: if/when you do decide to add this, consider disabling notifications for actions. Otherwise tests may generate a lot of notifications/emails.

[Quuxplusone]

That's pretty cool! Would there be an equivalent of Travis's red/green badges in the README or otherwise visible?

[still-flow]

By the by: I imagine it's possible to add a Windows build here too, but right now it's pointless for the same reason as discussed in #116.

[still-flow]

Would there be an equivalent of Travis's red/green badges in the README or otherwise visible?

Yup, there is a "Create status badge" button on the right and a bit below the top in my example which probably does just that.

Seems to work. There are various options there which I don't know anything about, but looks snazzy.

[still-flow]

Managed to set up a simple Windows build. Unfortunately, Github's Windows environments are running PowerShell as their main shell, so Windows builds will have to be separate from the Unix matrix.

EDIT: nvm that, actually you can select the default shell. That makes everything much easier.

[still-flow]

Hm, I really screwed this PR up, it would seem. Just tried to rebase the proposed changes (and new stuff too) onto the master branch which has since been updated, but this looks like it failed miserably.

UPD: Reopening the PR apparently fixed things.

[still-flow]

And here are the results for the current master. A lot more green, taking into account disabling the "remove -Werror" crutch. At this point I feel it's ready to leave the draft stage. One problem could be that currently there is a lot of duplication between build stages in windows and main_matrix, which could probably be solved via off-loading these sections in a script, but then there would be a problem of correctly passing envvars into script on Windows.

[still-flow]

I couldn't resist the temptation to make things just a bit less inelegant, so here is the result. At least nothing broke compared to the previous time. Ubuntu-clang-mymake builds seem to have a problem with the ordering of the log's output, which is somewhat troubling, but that was present without separation into scripts too. I'm not sure what to do with that.

[still-flow]

@zenorogue, would you be interested in this? AFAIK this works as it should now, here is an example of the output (mind you, my master is pretty old right now, so there are more errors than there would be now).

[zenorogue]

Thanks! I think it looks nicer than the current Travis configuration. Would that replace Travis, or is there a point to keep both? I assume the badge needs to be replaced/added to README.md, is there anything else to do?

[still-flow]

The only thing that's sort of different from Travis is that I wasn't able to find a way to display different badges for different build targets (e.g. "web", "autotools", etc.). I honestly don't know if one is better than the other, however Github seems to be a bit faster? And maybe "the more, the better" philosophy applies in this case, too.

[zenorogue]

It seems that some targets currently fail -- as far as I can tell, this is because RogueViz requires c++17. With mymake it should be sufficient to add an option -std=c++17, not sure about autotools.

[Quuxplusone]

FWIW, I'd agree that "the more, the better." (And I continue to think that if autotools is giving you trouble, just throw it overboard. ;))

One downside of GitHub CI seems to be that it very quickly recycles the logs: this says "The logs for this run have expired and are no longer available." Whereas in TravisCI you can currently go back six months or more.

Also, Travis's "build history" seems quite discoverable and intuitive, whereas I can't figure out how to navigate or really do anything in GitHub CI. But that might just be a side-effect of having the CI stuff in a branch instead of master, I dunno.

[still-flow]

With mymake it should be sufficient to add an option -std=c++17

Would you like me to add it to workflow config?

One downside of GitHub CI seems to be that it very quickly recycles the logs

I was able to find this topic from a month ago in which this very issue is raised. The reply suggests giving feedback through a special form, which OP presumably used, but maybe it's worth to use it again?

On a related note, it's possible to download logs manually (which btw apparently contain more information than is available via GUI), and a shoddy workaround could be to somehow save that data as a build artifact. The trouble is that there is no obvious way to get the download link from within the build environment.

[zenorogue]

Would you like me to add it to workflow config?

Yes please!