Add CI workflow

[kuhnroyal]

This PR adds a CI workflow to the project with format check, linting, tests and builds of the example app.

There are currently 3 failing tests.

[781flyingdutchman]

Interesting - I am not familiar with this CI workflow but it seems really helpful. I can probably fix these 3 tests (they are a bit older) but the bigger issue seems to me that the more complex and numerous tests are all in the example/integration_tests folder. Any chance you can modify the workflow script to run those tests as well, on Android, iOS and Linux (adding MacOS and Windows is likely harder)? Some of those tests are a bit flaky (e.g. depend on the speed of the network connection) so you will likely see a few failures there too, but I can figure out how to 'harden' them, or comment them out if I cannot. It would be super helpful to have this as a test before publishing the package, so thanks for doing this!

One more question: can I run this workflow on the 'dev' branch before merge it into 'main'? That's how I usually do this to make sure 'main' stays aligned with the published version.

[kuhnroyal]

Sure, I can add manual workflow dispatch triggers and also for PRs targeting the dev branch.
Will check for the integration tests tomorrow. Didn't see that :o

[kuhnroyal]

I updated the workflow, the manual run should work once this file is in the default branch.
Could you take a look at the failing tests?

I suggest to merge this once it is green and tackle the integration tests separately.
I also have errors in the integration tests and have no experience running them on Github Actions, so this will take a while.

[kuhnroyal]

The integration tests also run for some time 6-7 mins on my local machine. If we run this for all platforms in CI we might hit usage limits.

But we could look at patrol to see if we can automate the permission requests: https://leancodepl.docs.page/patrol/native/usage#permissions

[781flyingdutchman]

I merged both PRs (including the deadlock one) into the dev branch, and modified the tests so they pass. Some of the download tests (including the integration tests) will be flaky, as some are written with fixed time delays and can fail if download is exceptionally slow or fast. I don't really want to change that, so let's see how the integration tests do on in the CI workflow and I can modify a few if needed to let them pass.

Per documentation each job can run 6 hours, so I think we should be fine with the 6 min integration tests per platform, so would really like this added as it will save me time (I run these manually on all platforms before I publish, which is a bit of a pain) - let me know if you can do that (based on dev preferably), and then I'm happy to push this as the next version.

Also, please don't check in Podfile.lock.

[781flyingdutchman]

Now I'm getting notifications that the workflow didn't run without errors. The test errors are still there, but also new errors related to Cocoa pods. Not sure what those are about.

[kuhnroyal]

Well yea, the workflow relies on the Podfile.lock to install a predictable cocoapods version :)

[kuhnroyal]

So... I added a workflow for integration tests in my fork here: kuhnroyal@d26c063

But unfortunately I don't think this is very practicable - it runs for 50min on each platform.
The problem here is that the free runners from Github are all very small resource wise.

https://github.com/kuhnroyal/background_downloader/actions/runs/11160886074

[781flyingdutchman]

I see - that also explains the test errors when they are somewhat dependent on download speed.
In that case, I think it's better to remove all tests from the workflow, because it's really the 100+ integration tests that matter most.

And sorry about the PodFile.lock - I really don't want to check it in though, because it creates merge conflicts that are annoying and unhelpful in this context (I understand it may be valuable in team dev settings, but this is an example app). Is there a way to test that the app builds without having to commit that file? Ideally it just takes the latest of all the packages in pubspec.yaml for each variant of the build.

Thanks again for your help - didn't realize this would be so difficult!

[kuhnroyal]

I removed the podfile and updated the workflow.