Use Shared CI Workflows

[rmartin16]

Changes

• Configures Dependabot for the repo.
• Enabled basic pre-commit checks.
• Ensures the repo is tested against Windows Store Python.
• Ensures Briefcase is installed from main or using appropriate git tag.
• Implements shared workflows from Centralize More Universal CI Actions .github#8
  • pre-commit-run
  • app-build-verify

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[rmartin16]

Leaving at draft for now. The caching may not be working....and thinking about it, app packaging should probably have failed with the Windows Store Python and Briefcase from PyPI....but it's not...

Needs more investigation.

[freakboy3742]

While we're here, we should probably add 3.12-dev

[rmartin16]

I don't think this'll work unless a binary stub is also created for 3.12.

[freakboy3742]

Ah - good point; and we can't do that until there's a NuGET release of Python 3.12.

[rmartin16]

I tracked it down. The GitHub runner comes with WiX preinstalled; so, Briefcase wasn't installing and using its own version. Unsetting the WIX environment variable allows Briefcase to ignore the existing WiX install.

CI now fails for the Windows Store Python and this PR needs to wait on Briefcase v0.3.12.

CI Run using Briefcase main branch: https://github.com/beeware/briefcase-windows-app-template/actions/runs/4026447475/jobs/6921190001

[rmartin16]

While caching the Briefcase cache directory nullifies a lot of the rationale for testing against Windows Store Python, it still seemed like a good idea to keep in place.

Github caches are evicted after 7 days. Given this repo doesn't get many PRs, it is likely the action will run without a cache available. I've also included the python source as part of the cache key; so, a cache will only be available for subsequent runs if a previous run succeeded. This helps avoid papering over a failure because the next run would pull the successfully created cache from the github python job.

[freakboy3742]

These changes look good; it's currently failing CI due to a timeout running WiX - but I'm not sure if that's just Github having a moment. I've kicked off a re-run just in case.

Good catch on the fact that this is dependent on Briefcase 0.3.12 at present; while "waiting" will fix the problem, I actually think the bigger problem is that the template should be running with the dev version of Briefcase, not a formal release. The main branch of the template will be used by the main branch of Briefcase; so that should probably be reflected in our CI as well.

The only reason we should be using an officially tagged Briefcase version in CI is when we're merging into a specific branch (i.e., a fix to the 0.3.11 template branch), and that version number has been tagged in the Briefcase repo (e.g., when we cut the 0.3.12 branch, there will be a short window where the 0.3.12 branch exists, but Briefcase 0.3.12 hasn't been released yet). In all other cases (merging to main, merging to a pre-release Briefcase), we should be installing the current dev version of Briefcase.

[rmartin16]

These changes look good; it's currently failing CI due to a timeout running WiX - but I'm not sure if that's just Github having a moment. I've kicked off a re-run just in case.

It's timing out because WiX is failing to launch heat.exe because it's looking for it in the wrong place. With a GUI, you get that dialog error message....in GH CI, it just locks up.

I'll see about getting Briefcase dev installed for testing.

[freakboy3742]

It occurs to me that the Github actions logic to determine "install the version of Briefcase that matches the branch of this PR" is going to be moderately complex logic that we will probably want to use in every template; so it's a good candidate for factoring out into the .github repo.