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

ci: Implement static checks for demos #25

Open
8 of 16 tasks
theCapypara opened this issue Oct 28, 2023 · 5 comments
Open
8 of 16 tasks

ci: Implement static checks for demos #25

theCapypara opened this issue Oct 28, 2023 · 5 comments

Comments

@theCapypara
Copy link
Contributor

theCapypara commented Oct 28, 2023

For GitHub actions (and locally using make ci), implement the following checks for all demos:

  • For Vala and Rust make sure the demos compile
  • For Rust and Vala make treat warnings as errors. For Rust consider whether it makes sense to use some Clippy lints as well or not
  • For JavaScript check eslint
  • Check that the demos follow the same formatting as the tools provided by Workbench:
    • For Rust: Make sure the code is formatted using rustfmt
    • For JavaScript: Use Biome in Workbench for formatting to match CI
    • For JavaScript: Check against `biome``
    • For Python: Make sure code follows PEP 8 (see also PEP 8 formatting for Python code Workbench#707)
    • For Python: Check against a linter (see also Python: Linting Workbench#804)
    • Check CSS against prettier
    • Check XML against prettier we don't have xml files in demos
    • Check Blueprint against blueprint-compiler's fomat command.
    • blueprint compile to check blp -> xml
    • blueprint port to check xml -> blp
  • Python: Using pygobject-stubs and either mypy or pyright check that the demos pass static type checks
  • JavaScript: If possible try to statically type check the demo JS files (for example using TypeScript's tsc and ts-for-gir)
  • Check Blueprint files against blueprint-compiler

Some of these are already implemented.

All tests must be executable based on the Flatpak SDK workbench uses (see existing CI taks in the Makefile).

Required boilerplate, configuration files and stubs should be kept to a minimum and somewhat isolated from the rest of the code base. However note that some of prettier and possible some other JS libraries for formatting are already bundled with Workbench and those should be used.

I'm a bit unsure about the JS and Vala side of things, so some things may not make perfect sense, happy for comments on this!

This is related to #24, but the demos are not actually run, they are all checked statically. This should probably be constructed in a way that makes it somewhat easy to add testing to run the demos later on.

@theCapypara
Copy link
Contributor Author

Note that even with this issue we can not check that the Blueprint files actually match the demos, this will require #24.

@sonnyp
Copy link
Contributor

sonnyp commented Oct 29, 2023

@theCapypara
Copy link
Contributor Author

We may also want to check for missing version requirements in the demo or missing init calls. See also workbenchdev/Workbench#738

@theCapypara
Copy link
Contributor Author

Updated the issue to contain checkboxes for tasks and checked what is already implemented.

@sonnyp sonnyp transferred this issue from workbenchdev/Workbench Dec 9, 2023
@sonnyp
Copy link
Contributor

sonnyp commented Dec 18, 2023

For JavaScript: Make sure code is formatted/linted using prettier

I fixed that the other way around - Workbench now uses biome instead of prettier for formatting JS

Since we already use Biome for CI on demos - this point can be checked

EDIT: actually I rephrased it

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

No branches or pull requests

2 participants