Add CI job to build calculator app

[alexrudd]

Description:

Opening this as a draft PR to get feedback around building for darwin and ios.

This PR adds an additional job to the GitHub Actions CI Workflow that uses fyne-cross to build the Fyne example calculator project. It also makes some small changes to the linting and testing workflow jobs for consistency and compatibility reasons.

The aim of this additional job is to try and catch integration issues that only occur when using fyne-cross to build an actual app. See this bug report for some context: #100

I'm looking for feedback on the following:

• Is there a clean way to build a Fyne app for darwin or ios targets using the macos GitHub Actions runner? According to the docs the macos running comes with Xcode Command Line Tools installed, but they're not available as a dmg to reference using xcode-path.
• Should these jobs be run for multiple versions of Go? I don't know what the rationale is behind the current Go versions in the workflow, but I have updated them to be the latest and minimum support versions of Go for the project.
• Do we trust that the Calculator project will not introduce bugs that cause the build to fail unrelated to fyne-cross? We could pin to a specific release of the Calculator if so.

I'd welcome any and all feedback :)

Checklist:

• Tests included.
• Lint and formatter run with no errors.
• Tests all pass.

[alexrudd]

Here's a link to a completed run in my fork, including the failed darwin-image builds: https://github.com/alexrudd/fyne-cross/actions/runs/2145041714

[lucor]

Thanks for the PR @alexrudd, great job!

Is there a clean way to build a Fyne app for darwin or ios targets using the macos GitHub Actions runner? According to the docs the macos running comes with Xcode Command Line Tools installed, but they're not available as a dmg to reference using xcode-path.

At the moment I think testing the compilation from host darwin to target darwin is good enough. This means running something like:
fyne-cross darwin --app-id <app-id> ...

In this case fyne-cross will use the SDK provided by XCode and there is no need to create the darwin image (required only when building from a no macOS host).

Same applies to iOS. The build is supported only on macOS systems.

Should these jobs be run for multiple versions of Go? I don't know what the rationale is behind the current Go versions in the workflow, but I have updated them to be the latest and minimum support versions of Go for the project.

I'd say minimum and latest is ok.

Do we trust that the Calculator project will not introduce bugs that cause the build to fail unrelated to fyne-cross? We could pin to a specific release of the Calculator if so.

Testing against the Calculator project is fine for now. In the worst scenario where a build fails due to bug from the app means the CI helped to found some issues into the Calculator app / Fyne toolkit :)

[alexrudd]

The darwin builds are now working (at least when there are available runners), just need to spend some time figuring out why the ios build can't find a certificate:

/Users/runner/go/bin/fyne package -os ios -name calculator -icon /Users/runner/work/fyne-cross/fyne-cross/calculator/fyne-cross/tmp/ios/Icon.png -appBuild 1 -appVersion 1.0 -appID calc.005000ea9d717a78c73b614c509bcaa68aad2725
failed to look up certificate : exit status 44

There's quite a different error in the go1.13 ios build that I'll look into too. Might be a bug in go 1.13 from some initial googling

[andydotxyz]

There's quite a different error in the go1.13 ios build that I'll look into too. Might be a bug in go 1.13 from some initial googling

Fyne only supports down to Go 1.14

[lucor]

@andydotxyz good catch. Min version bumped in #110

WRT the ios build failure my guess is that requires a certificate profile that matches the appID.

Wondering if it is possible to upload on Github a testing certificate and share as secret ?

[andydotxyz]

Wondering if it is possible to upload on Github a testing certificate and share as secret ?

The way cert lookup currently works is by having it registered with the system then look it up by name (as that is how Apple dev works by default).
We could overload this feature to offer path as well (would need to do the same for provisioning profile I think).

[Bluebugs]

It seems to me that adding ios support for this github action is going to take more time. Why don't we remove it at the moment and open an issue to work on it? This way we can already merge this PR which is useful.

[lucor]

Why don't we remove it at the moment and open an issue to work on it? This way we can already merge this PR which is useful.

I agree.

[alexrudd]

Sorry for the delay. Had a busy few weeks!

Here's the workflow with the ios target commented out and rebased onto latest develop. I can completely remove ios from the build matrix if that's preferred.

[lucor]

LGTM, thanks @alexrudd
I'd great to have a @Jacalz 's review before merge.

[Jacalz]

Thanks a lot for this. It looks good to me :)