Skip to content

ci: Implement static checks for demos #25

@theCapypara

Description

@theCapypara

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions