Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify app user data path for testbed on Windows #2235

Merged
merged 1 commit into from
Nov 19, 2023

Conversation

rmartin16
Copy link
Member

@rmartin16 rmartin16 commented Nov 18, 2023

Changes

Notes

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 rmartin16 changed the title Specify app user data path for tested on Windows Specify app user data path for testbed on Windows Nov 18, 2023
@rmartin16 rmartin16 force-pushed the testbed-app-data-dir branch 4 times, most recently from 4b6faa8 to 716d5e7 Compare November 18, 2023 17:12
@rmartin16 rmartin16 marked this pull request as ready for review November 18, 2023 20:10
Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conceptually, this all makes sense.

My only hesitation on approving and merging is that I can't make sense of the example provided for the "proof it works" case. The testbed tests have all been marked as failed... but with no test failure or coverage problems.

I'm presuming this is an artefact of rewriting history, and you manually added a "return 1" to the test case or something?

However, even then - only Windows and Linux have presented app data artefacts after the build - iOS, Linux and macOS have no app data. I can't tell if this is a side effect of the $HOME changes, or an artefact of how the test was made to fail.

As for whether these artefacts are useful - they're generally only useful if a test fails.

The app data is particularly useful for the canvas tests, which generate images of the appearance of the canvas when they fail. This was essential when developing those tests, because we were getting failures caused because the rendering of the canvas wasn't pixel-perfect the same with desktop machines (for any number of reasons). Exfiltrating the app data gives us the actual output under test conditions, which we can compare with local output and work out if there's an actual problem, or just a sub pixel variation caused by some local test condition.

The logs are there mostly for additional debugging when the failure is for Briefcase failures - those don't normally happen, but when they do, it's useful to know the exact machine state when the failure occurred. There's an argument to be made that we should always be running with --log, and then uploading all the artefacts if a failure occurs, in case there's something else going on.

@rmartin16
Copy link
Member Author

Conceptually, this all makes sense.

My only hesitation on approving and merging is that I can't make sense of the example provided for the "proof it works" case. The testbed tests have all been marked as failed... but with no test failure or coverage problems.

I'm presuming this is an artefact of rewriting history, and you manually added a "return 1" to the test case or something?

That's correct; I just forced the testing step to fail after the tests completed.

However, even then - only Windows and Linux have presented app data artefacts after the build - iOS, Linux and macOS have no app data. I can't tell if this is a side effect of the $HOME changes, or an artefact of how the test was made to fail.

I was confused by this as well but is also why I included a link to a recent run before this change that also failed wit the same missing artefacts. I wasn't sure if these directories were wrong....or if the tests never produced data on those platforms.

Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh... ok, I've found the source of the two outputs.

The Windows one is a known problem. The app data is a set of images that can't be reliably cleaned up because of Python.net retaining open file references. The "forced fail" means we see the mess that was left.

The GTK app data is some transient storage from the webview test. Again, the forced fail means we see the mess; these files would be included if there was a canvas or image failure, but they'd normally of no significance.

So - looks like you're right that nothing has changed. The artificial nature of the test was just surfacing things we wouldn't normally see.

@freakboy3742 freakboy3742 merged commit 0eaf2c0 into beeware:main Nov 19, 2023
35 checks passed
@rmartin16 rmartin16 deleted the testbed-app-data-dir branch November 19, 2023 02:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants