Run apps created in `app-build-verify` #69

rmartin16 · 2023-11-18T09:04:08Z

Changes

Run briefcase run for apps created with app-build-verify
Introduce new "Briefcase Automation" plugin
- This plugin replaces the app.py with a version that will automatically exit shortly after the app starts
- Introduce package for Briefcase Automation briefcase#1549
Use the GitHub provided WiX install
Use the GitHub provided Java 17 install
Use Fedora 39 to test RPM packaging (instead of Fedora 37)
Closes Add a "live test" to template CI briefcase-template#75

Notes

With some cheats, all frameworks are running on all platforms (where frameworks are supported at all)
briefcase run is not called for apps created for Linux via containerization since Briefcase does not support the Run command when --target is specified (and that's because passing the X11 into Docker is convoluted).

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 · 2023-11-19T15:29:34Z

An interesting conundrum.

If another repo, like beeware/briefcase, invokes a version of this workflow that isn't at beeware/.github@main, how do you ensure that subsequent workflows and actions are also from that same non-main branch?

Notably, consider Briefcase's CI calling app-build-verify but from a branch on my fork, i.e. rmartin16/.github-beeware/.github/workflows/app-build-verify@testing-branch. This, of course, works fine but app-build-verify needs to run the app-create action to roll out the Briefcase project for testing. It does this by referencing the app-create action via a local filesystem path to the .github repo.....and hence, where the problem begins: how do you checkout the .github repo for the version of app-build-verify that's currently running?

This will require knowing the repo and branch where the running app-build-verify lives.

rmartin16 · 2023-11-19T16:38:52Z

Another person pointed out this same issue. They did not really come to a reasonable conclusion, though...since their workable solution was a hacky javascript action that manually inspects the environment to derive where the running reusable workflow lives....and using some OIDC context at that.

The core problem is mostly how inheritance works. When the reusable workflow (i.e. app-build-verify) is called, it inherits the environment from the caller; this includes the github context.

Relevant bits of github while app-build-verify is running when Briefcase calls it in a PR:

github.ref_name=1546/merge
github.repository=beeware/briefcase
github.repository_owner=beeware
github.workflow=CI
github.workflow_ref=beeware/briefcase/.github/workflows/ci.yml@refs/pull/1546/merge
github.workflow_sha=37da207f9e010c326f1c0a93730e1fd02209e57c

So, the reusable workflow being called effectively appears to just be a part of the workflow that called it.

This means a naked actions/checkout step in app-build-verify will checkout beeware/briefcase and not the repo for the version of app-build-verify that's running.

There doesn't appear to be a straight-forward way for a reusable workflow on a non-main branch to naturally use other reusable workflows/actions from that same branch. Hell, when they first added reusable workflows, they apparently didn't even have way to specify workflows in the same repo without explicitly specifying the same org/repo....so, this problem initially existed even when trying to test reusable workflow changes on a branch within the same repo. Referencing relative workflows was eventually added.

Anyway, I suppose I'll add inputs to app-build-verify to explicitly declare the repo to use for nested workflows/actions.

rmartin16 · 2023-11-29T21:44:44Z

Testing

Briefcase repo
- PR using these changes: Introduce package for Briefcase Automation briefcase#1549
- Shows app-create-verify not using the Automation plugin to create a Briefcase project
- Shows app-build-verify installing Briefcase from the packaged wheel
- Shows app-build-verify creating Briefcase project with Automation plugin
- Shows app-build-verify running app and exiting
Briefcase project template repo
- PR using these changes: [do not merge] test running briefcase run in CI briefcase-template#86
- Shows app-create-verify using the local repo checkout to create the Briefcase project
- Shows app-build-verify using the local repo checkout to create the Briefcase project
Briefcase build template repo
- PR using these changes: [do not merge] test running briefcase run in CI briefcase-android-gradle-template#74
- Shows app-build-verify using the local repo checkout to lay out the build directory

freakboy3742

A couple of questions for clarification purposes, and one minor cosmetic thing - but otherwise, I think this all makes sense, and it's difficult to argue with the success of the example cases you've provided.

I definitely can't see anything that is systematically wrong or will lock us out of a use case that we need to support; my only real concern is the level of complexity... but to some extent, this is just inherently complex.

freakboy3742 · 2023-12-01T05:29:30Z

.github/workflows/app-build-verify.yml

      if: >
        startsWith(inputs.runner-os, 'ubuntu')
        && contains(fromJSON('["Linux"]'), inputs.target-platform)
        && contains(fromJSON('["AppImage"]'), inputs.target-format)
      working-directory: ${{ steps.create.outputs.project-path }}
      run: |
+        PACKAGES="libfuse2"
+        case "$(tr '[:upper:]' '[:lower:]' <<< '${{ inputs.framework }}')" in
+          toga    ) PACKAGES="${PACKAGES} libthai-dev libegl1" ;;


libthai-dev? What's that for?

oh....this goes back to all our previous AppImage testing; libthai-dev is a deep transitive dependency for Toga but AppImage has excluded it from inclusion....so, this ensures it's available to load from the file system of the runner itself.

For completeness, here's the minimum apt packages to run Toga in an AppImage:

libthai-dev libfribidi0 libfontconfig1 libx11-6 libegl1 libgl1 libharfbuzz0b

All the other packages are already installed.

freakboy3742 · 2023-12-01T05:35:03Z

.github/workflows/ci.yml

@@ -229,8 +229,8 @@ jobs:
    strategy:
      fail-fast: false
      matrix:
-        framework: [ "toga", "ppb" ]
-        runner-os: [ "macos-latest", "windows-latest", "ubuntu-latest" ]
+        framework: [ toga, pyside6 ]


Not sure I understand this change. Is Pyside a better check?

Ah; this was a really early change I made when this was still POC. There isn't really a defensible rationale other than it took me a lot longer to get PPB working than PySide. I can change it back, though.

freakboy3742 · 2023-12-01T05:37:41Z

.github/workflows/app-create-verify.yml

-        briefcase-template-source: ${{ inputs.briefcase-template-source || steps.template.outputs.path }}
-        briefcase-template-branch: ${{ inputs.briefcase-template-branch }}
+        # use the current repo checkout if briefcase-template is being tested
+        briefcase-template-source: ${{ endsWith(github.repository, 'briefcase-template') && github.workspace || '' }}


I presume the drop of briefcase-template-branch is because we can't support non-main branches any more?

This is definitely a little more obscure; so, #68 added the ability to specify the briefcase template as part of the body of the PR; so, manually overriding it in the workflow isn't necessary anymore.

freakboy3742 · 2023-12-01T06:04:43Z

.github/actions/app-create/action.yml


-        echo "Rolled out project to ${APP_PATH} (${{ inputs.framework }}->${GUI_INPUT})"
+        echo "Rolled out project to ${APP_PATH} (${{ inputs.framework }}->${BOOTSTRAP})"


A minor cosmetic thing, but it took me a couple of tries to work out how to "read" this when it appeared in the logs. It might help to be more explicit about the framework and bootstrap choice.`

rmartin16 · 2023-12-05T00:53:46Z

This is all here now.

I'm not sure where we stand now with any further parameterization of app-build-verify; do you think it'll be worth abstracting these last few bits?

Otherwise, the only other question is CI for backports for templates. I think we'll just need to abandon running CI for such PRs; I definitely do not see any low-effort option to keep it working. Although, once Briefcase 0.3.17 is cut, CI would be able to run for backports to that version and later.

freakboy3742

All looks good to me.

Regarding the potential parameterisation: I think I'm happy for now. It isn't immediately obvious to me that parameterisation will result in something that is obviously better - I think we'd likely end up exchanging some complexity in this project for equal levels of complexity spread across all the templates (... or, straight up more complexity in both 😝).

We can always revisit this if one of us has a bright idea about how to simplify everything, but for now, the perfect is the enemy of the good, and what we've got definitely meets the bar of good (and then some).

rmartin16 · 2023-12-05T01:17:26Z

I just realized that CI for this PR should be re-run without BRIEFCASE_REPO in the PR body. Let me do that.

rmartin16 mentioned this pull request Nov 18, 2023

Run app during verify #67

Closed

4 tasks

rmartin16 force-pushed the build-verify-run branch 20 times, most recently from b361bb8 to e71d064 Compare November 19, 2023 14:39

rmartin16 force-pushed the build-verify-run branch 3 times, most recently from 5d24435 to 1ae64c7 Compare November 19, 2023 16:03

rmartin16 force-pushed the build-verify-run branch 4 times, most recently from 66d32b8 to 098cdb0 Compare November 19, 2023 18:02

This was referenced Nov 29, 2023

[do not merge] test running briefcase run in CI for backports beeware/briefcase-android-gradle-template#75

Closed

[do not merge] test running briefcase run in CI beeware/briefcase-android-gradle-template#74

Closed

rmartin16 force-pushed the build-verify-run branch 10 times, most recently from 9c55cb8 to ef90a31 Compare November 29, 2023 20:22

rmartin16 mentioned this pull request Nov 29, 2023

[do not merge] test running briefcase run in CI beeware/briefcase-template#86

Closed

4 tasks

rmartin16 marked this pull request as ready for review November 29, 2023 21:45

freakboy3742 requested changes Dec 1, 2023

View reviewed changes

rmartin16 force-pushed the build-verify-run branch 3 times, most recently from 30ab644 to f043605 Compare December 4, 2023 15:41

rmartin16 mentioned this pull request Dec 4, 2023

Package Automation with Briefcase in CI beeware/briefcase#1562

Merged

4 tasks

Run apps created in app-build-verify

f52e45e

rmartin16 force-pushed the build-verify-run branch from f043605 to f52e45e Compare December 4, 2023 23:54

rmartin16 requested a review from freakboy3742 December 5, 2023 00:55

freakboy3742 approved these changes Dec 5, 2023

View reviewed changes

Limit install-briefcase action testing to post v0.3.16

c3c299b

freakboy3742 merged commit fcde700 into beeware:main Dec 5, 2023
68 checks passed

rmartin16 deleted the build-verify-run branch December 5, 2023 03:04

rmartin16 mentioned this pull request Dec 5, 2023

Add a "live test" to template CI beeware/briefcase-template#75

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Run apps created in `app-build-verify` #69

Run apps created in `app-build-verify` #69

rmartin16 commented Nov 18, 2023 •

edited

Loading

rmartin16 commented Nov 19, 2023

rmartin16 commented Nov 19, 2023 •

edited

Loading

rmartin16 commented Nov 29, 2023

freakboy3742 left a comment

freakboy3742 Dec 1, 2023

rmartin16 Dec 1, 2023

freakboy3742 Dec 1, 2023

rmartin16 Dec 1, 2023

freakboy3742 Dec 1, 2023

rmartin16 Dec 1, 2023

freakboy3742 Dec 1, 2023

rmartin16 commented Dec 5, 2023

freakboy3742 left a comment

rmartin16 commented Dec 5, 2023


		echo "Rolled out project to ${APP_PATH} (${{ inputs.framework }}->${GUI_INPUT})"
		echo "Rolled out project to ${APP_PATH} (${{ inputs.framework }}->${BOOTSTRAP})"

Run apps created in app-build-verify #69

Run apps created in app-build-verify #69

Conversation

rmartin16 commented Nov 18, 2023 • edited Loading

Changes

Notes

PR Checklist:

rmartin16 commented Nov 19, 2023

rmartin16 commented Nov 19, 2023 • edited Loading

rmartin16 commented Nov 29, 2023

Testing

freakboy3742 left a comment

Choose a reason for hiding this comment

freakboy3742 Dec 1, 2023

Choose a reason for hiding this comment

rmartin16 Dec 1, 2023

Choose a reason for hiding this comment

freakboy3742 Dec 1, 2023

Choose a reason for hiding this comment

rmartin16 Dec 1, 2023

Choose a reason for hiding this comment

freakboy3742 Dec 1, 2023

Choose a reason for hiding this comment

rmartin16 Dec 1, 2023

Choose a reason for hiding this comment

freakboy3742 Dec 1, 2023

Choose a reason for hiding this comment

rmartin16 commented Dec 5, 2023

freakboy3742 left a comment

Choose a reason for hiding this comment

rmartin16 commented Dec 5, 2023

Run apps created in `app-build-verify` #69

Run apps created in `app-build-verify` #69

rmartin16 commented Nov 18, 2023 •

edited

Loading

rmartin16 commented Nov 19, 2023 •

edited

Loading