-
Notifications
You must be signed in to change notification settings - Fork 448
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
feat!: fail if we know the project is core24 #4557
feat!: fail if we know the project is core24 #4557
Conversation
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## feature/craft-application #4557 +/- ##
=============================================================
- Coverage 88.33% 88.20% -0.13%
=============================================================
Files 327 327
Lines 21961 21992 +31
=============================================================
Hits 19399 19399
- Misses 2562 2593 +31 ☔ View full report in Codecov by Sentry. |
f793720
to
4fb3c6b
Compare
4fb3c6b
to
1372d07
Compare
This commit updates the scaffolding to have a different behavior in cases where we *know* that the existing project (from the yaml file) is core24-based. In these cases, we now raise a RuntimeError outlining the name of the command instead of raising a ClassicFallback error to let the non-craft-application workflow take over. With this, Snapcraft runs on core24 projects will fail until the commands are ported over, while projects for older bases (or commands that don't use projects, like "init") will still fallback to the existing behavior.
These are all the tests from tests/spread/core22, copied over to tests/spread/core24. Completely unmodified, they therefore still have the core22 base.
This is a semi-manual update of "base" to "core24", "build-base" to "devel" and "grade" to "devel" (where applicable).
This commit does the equivalent of pytest's "xfail(strict=True)": all core24 tests are currently fail because no Snapcraft command has been implemented yet, so the test checks that the tool fails with the expected message, and then exits successfully. The idea is that once a command is implemented the corresponding spread tests will start to fail - we can then scrutinize each test to validate the new behavior.
e76e2fd
to
0abe95e
Compare
I had to force-push this to re-seat it on the new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work! Looks like we will have to adjust the required CI jobs for this branch
The intention here is to speed-up spread runs and make the development loop faster. I've run the non-core24-tests in this feature branch and can confirm that they pass (or have unrelated failures).
0abe95e
to
d8567cd
Compare
thanks! I updated the workflow to keep the name of the required step |
The purpose of this PR is two-fold:
A lot of the changes are copied over from existing tests, so some commits can mostly be skimmed. I tried to split them up in a way that makes functional sense (to me at least):
tests/spread/core22/
. These tests are unchanged and still havecore22
as base, so they don't need a big review;snapcraft pack
are expected to fail with"pack" command is not implemented for core24
. The tests now check for this message and exit.tests/spread/core24
. I confirmed that the other tests are passing, and restricting this feature-branch to only core24 tests speeds up the development loop considerably.