Add support to pass arguments through to Docker image build

[rmartin16]

Changes

• Allow passing arguments to docker build
• RE: Use ghcr.io for Docker image caching .github#99

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]

Added buildx so it is explicit that buildx is building the image. Added --load because it is only implied when using the default build container; if you use a custom one, the image isn't loaded in to the local Docker image cache.

[freakboy3742]

No objection to doing this bump if it's needed, but I'm interested what bug/feature has required it?

[rmartin16]

Using pre-2.6.0 and 2.6.0 produces two different files for app.py and __main__.py. I didn't track down the exact thing that changed but 2.6.0 introduced a way to control the jinja tag boundaries....so, thinking about it now, maybe a regression was introduced around how {% %} is replaced in a template....I should probably check how our other templates look now.

At any rate, CI was failing with 2.6.0: https://github.com/beeware/briefcase/actions/runs/7993409808/job/21829525533

[rmartin16]

We should hold off. There's all kinds on new newlines in pyproject.toml with 2.6.0.

[rmartin16]

well, actually, i guess it doesn't matter....2.6.0 is going to be installed regardless...so, I guess we may as well move forward and resolve this regression independently.

[rmartin16]

• Whitespace control behavior different in v2.6.0 cookiecutter/cookiecutter#2023

[rmartin16]

To explicitly lay it out, I think these are the options I see to move forward:

• Bump to require 2.6.0 as I have here
  • This would accommodate the whitespace changes in 2.6.0
  • Once/if these are resolved in cookiecutter, we can revert the changes and bump to that new version
• Lower the upper bound from <3.0 to <2.6.0
  • This will obviously maintain the status quo
  • Once/if the issue is resolved, we can increase the upper bound again

Let me know what you think. As a note, CI for all PRs for Briefcase will fail until this is addressed.

[freakboy3742]

I guess a third option is "!=2.6.0", if we have reason to believe that 2.6.0 is an isolated buggy release and the issue will be fixed in 2.6.1.

My inclination for now is to use "< 2.6.0" until we know whether this is an intentional change (or, at least, a change that won't be rolled back), or a bug that will be resolved. If this is the "new normal", then we should set the 2.6.0 as the new minimum; if it's a bug that gets fixed, we can exclude the specific problem releases.

[rmartin16]

Good deal; I agree...especially since the issue is more widespread than I initially thought.

• Remove upper bound pin <2.6.0 for cookiecutter #1663

[rmartin16]

Another question that came up for me while I was implementing this:

Do you see value in keeping LinuxSystemPassiveMixin and LinuxSystemMostlyPassiveMixin as separate classes still given that LinuxSystemRunCommand now depends on the build system?

Some of the separation is already a little fuzzy to me....but I was also considering collapsing some of these forks in the code for whether the build system is the local machine or in Docker and just using the same logic for both via calls to tools[app].app_context.run().

[freakboy3742]

Do you see value in keeping LinuxSystemPassiveMixin and LinuxSystemMostlyPassiveMixin as separate classes still given that LinuxSystemRunCommand now depends on the build system?

You're not alone in having this thought. I can't remember which PR I was working on where this case up, but I noticed the same thing. It was an optimisation in the past, but I'm fairly certain the use case for "mostly passive" no longer exists. I didn't get quite as far as doing the refactor, but if we can get rid of the "Mostly", I'd be happy to sign off on that.

[rmartin16]

CI looks good now 🦾 once this is merged, I will re-run CI for beeware/.github#99 and re-base #1649; both of those should then be ready to review/merge.

[freakboy3742]

👍