Experiment with GitHub Actions #940
Conversation
olafurpg
force-pushed
the
actions
branch
5 times, most recently
from
3ee0602 to
fed03fd
Compare
|
It looks like it's not yet possible to re-run individual job failures that are caused by flakyness https://gh.neting.ccmunity/t5/GitHub-Actions/quot-This-check-suite-has-disabled-re-running-individual-check/m-p/31696 |
|
@tgodzik do these error ring a bell? From https://github.com/scalameta/metals/pull/940/checks?check_run_id=233844637 |
|
Looks like we should try to split the |
.github/workflows/ci.yml
Outdated
| strategy: | ||
| matrix: | ||
| scala: | ||
| - "2.13.0" |
There was a problem hiding this comment.
We'll need to add a sbt command to auto-generate this matrix to ensure it's in sync with the build. I don't expect to merge this PR for now because GitHub Actions don't support re-running individual checks yet. I'm just trying to get a feel for how much we can push it 😄
There was a problem hiding this comment.
We will also need to ensure that the unit/test cross-matrix covers all the packages under tests
There was a problem hiding this comment.
| @@ -191,7 +191,7 @@ object PackageIndex { | |||
| Classpath(v).entries | |||
| }.toList | |||
| entry <- entries | |||
| if entry.isFile | |||
| if entry.isFile && !entry.toNIO.endsWith("jfr.jar") | |||
There was a problem hiding this comment.
what's jfr.jar? Maybe this is worth a comment?
There was a problem hiding this comment.
Good point, added (but not pushed yet).
olafurpg
force-pushed
the
actions
branch
3 times, most recently
from
d6896ef to
0ec502f
Compare
| "Mtags" -> githubActionsJob( | ||
| "Run tests", | ||
| "csbt ++${{ matrix.scala }} cross/test", | ||
| githubActionsMatrix("scala", V.supportedScalaVersions) |
There was a problem hiding this comment.
@milessabin One option for syncing the CI with crossScalaVersions is to automatically generate .travis.yml from build.sbt. In this PR we're using GitHub Actions but the same approach should work for Travis CI.
There was a problem hiding this comment.
@olafurpg you must be pulling my leg ... @djspiewak told me this is "fundamentally impossible"! ;-)
But seriously ... thanks for the pointer :-)
There was a problem hiding this comment.
It doesn't even seem necessary to print YAML, you can print JSON as long as the filename stays travis.yml
There was a problem hiding this comment.
In this PR we're using GitHub Actions but the same approach should work for Travis CI.
It doesn't work with travisci unless you commit the results. If Github Actions has multi-stage builds without a need to hard-commit results and allowing configuration shifts between stages, then it would be capable of this, but Travis' architecture doesn't support that.
There was a problem hiding this comment.
It doesn't work with travisci unless you commit the results.
When did I ever say I didn't want to commit the results!?!
- separate lint jobs - quote sbt commands
Avoids leaking the noisy 'slow/testOnly --' prefix in the GitHub UI.
This is a hack to see if we can get the CI passing on GitHub Actions.
To ensure that we continue testing all supported Scala versions and all `unit/test` packages, this commit tries to autogenerate the data from the build.
Scala all the things \o/
- incorrect resource paths - cleaner build matrix - support multiple steps in the same job
|
I'm gonna close this PR for now as an interesting experiment.
There are too many unrelated changes in this PR mixed together for me to feel comfortable merging it. I think it's best that we consider switching by incrementally enabling parts of the build. |
GitHub Actions (https://github.com/features/actions) offer a promising alternative to Travis CI. This PR sets up automatic CI releases for this build via GitHub Actions so that we can disable the Travis, Appveyor and Azure CIs.