Does this work with github actions?

[jkeen]

Flatware works like a charm locally, but I've been trying to get this to work with github actions and am having a helluva time. I'd love to see some instructions in the readme for getting flatware working with CI

[briandunn]

So happy its working for you! I never really intended this project to work in CI - most platforms seem to have their own thing. knapsack seems to be trying to parallelize rspec for CI.

I'd be open to adding features to enable this with flatware, if they aren't too much of a departure from the main goal of fast local runs with pretty output.

What kind of problems are you seeing trying to get flatware running? did #66 come up? Aren't those machines essentially single core? No idea how you would do this on actions, but it's possible you could distribute via DRb with the --sink-endpoint flag to flatware rspec. Would need to add flags like --sink to prevent the main machine from trying to work, and --work to prevent the other machines from starting sinks... but that wouldn't be too invasive and may be useful locally too.

[KieranP]

@briandunn Don't know if this will help, but this command prints all specs:

bundle exec rspec --format json --out tmp/rspec-all-specs.json --dry-run

From there, you can easily divide between X workers

[mjankowski]

After a few rounds of banging heads on various service integration (slow feedback loops), I wound up with a working GH Actions CI config.

• Relevant base config - https://github.com/mastodon/mastodon/blob/f1300ad284d8c7877a7406e253cf7558596d9837/.github/workflows/test-ruby.yml#L135-L140
• A helper file - https://github.com/mastodon/mastodon/blob/f1300ad284d8c7877a7406e253cf7558596d9837/spec/flatware_helper.rb

I wanted to preserve the ability to run the suite without flatware out of an abundance of caution for whatever automated scripts might exist, hence some of those conditionals.

I still think there might be more research to be done in the simplecov report combining and formatting realm, esp re: full branch coverage (there are a bunch of open issues on repo, I didn't find obvious solution).

The GH actions stock free runners for open source projects tend to have either 2 or 4 cores, so there's some benefit to be had there. Presumably with more substantial configurations it would still work and you'd have even more benefit.

I haven't played around yet with the time balancing feature from the persistence file on CI (I assume its working locally) - that may be next step (cache/restore persistence between runs).