* so I'm not running `publish.sh` at all. Maybe it also does some extra testing? Either way, that difference shouldn't affect most of these conclusions I think.
Initial impressions follow.
- Initial
setup was surprisingly painless. The full process from "let's try it"
to "test passed" took about 30 minutes (!!!). You create a YAML file
under .github/workflows (AFAICT you can have any number of workflows
that can be triggered in parallel if that makes sense for a project)
- The syntax / structure is pretty close to Travis, but:
- The
Docker "service" is always enabled. By default you run on the host, but
can also tell GH to instead run the whole thing inside a container (and
configure that container)
- There are no built-in "services", but you can configure any number of auxiliary Docker containers as you like
- `sudo` works on the host
- There are
a ton of built-in "steps" published via the GitHub Actions Marketplace.
There are basic ones like "install JDK" (which I used) but also super
fancy ones like "do a vuln scan on my Java codebase" (which I did not
use). Check it out: https://github.com/marketplace?type=actions
- The
current "set up JDK" step supports only Zulu, but there's active work on
making it support OpenJDK as well (and default to it, actually)
- There's
support for configuring what kind of events trigger the workflow (like
"commits on branches matching this regex"). The full workflow definition
reference is at https://help.github.com/en/articles/workflow-syntax-for-github-actions.
- Negative matches are supported, so we can translate our "only on non-release branches" condition from the Travis job
- There
is currently no support for caching intermediate build artifacts or
dependency caches (don't know if this is planned or not)
- There's support for secrets, which are edited via the Settings page of the repository, and can be read from the workflow.
Overall,
this looks pretty promising: it seems that mostly there is feature
parity with Travis (for our purposes at least), and my experience has
been roughly the same level of delightful as with Travis. I strictly
prefer the secret management solution of GH Actions to the solution in
Travis. The build log viewer UI is a bit on the rough side, but
functional.
At this point I'd recommend we
keep a close eye on GH CI. If (and this is a big if) GH Actions CI
brings bigger limits, or more stability than Travis, then there might be
a strong case for switching to it from Travis. There might also be
something to say for cool GH integrations, though I'm not exactly sure
what that would actually mean.
My overall conclusion is a cautious "looks good, let's see where it goes and maybe do some PoCs / experiments after GA".