Skip to content

Latest commit

 

History

History
69 lines (47 loc) · 2.82 KB

CONTRIBUTING.md

File metadata and controls

69 lines (47 loc) · 2.82 KB

Contributing

Thank you so much for having interesting in contributing to the project.

Issues reporting

  • crashes, panics and such should be reported there directly. Code should not crash, it is a bug.

  • missing or wrong arguments, errors with response, etc are most likely caused by wrong OpenAPI schemas. please report here, but do not start working on addressing those since they need to be fixed either in codegenerator or in the service itself.

  • missing commands in the CLI are most likely not enabled yet (generated by the codegenerator, but not included/imported yet as modules). Please report an issue or propose PR including generated modules in the source code.

Code Generation

Most parts of the code are automatically generated by https://opendev.org/openstack/codegenerator and therefore direct changes to the generated code are not making sense. Instead the codegenerator should be adapted where necessary. This approach forces code to be consistent.

All generated modules have a corresponding notice in the header.

if you have an idea how generated code can be improved open an issue or discussion.

Rust design decisions:

  • If a function needs to take ownership of the data, pass by value

  • If a function only needs to read the data, pass a reference (borrow)

  • If a function needs to change the data, pass a mutable reference.

Linters and co

  • pre-commit is present in the repository to help ensuring linters will not complain later. just issue pre-commit install in the repository root to enable it.

  • spell checking is performed using 'crate-ci/typos' and is a mandatory check.

  • doctstrings in generated files are produced from OpenStack services code. There is no point fixing them here and instead syntax or typos should be fixed upstream. The only exception is that during code generation spelling issues are automatically addressed by typos -w.

Releasing

There are 2 projects being used to take care of release process:

  • release-plz validates challenges and prepares PR to cut a release proposing the corresponding version. Merging PR will trigger release-plz to create new version, tag it, perform Rust release to <crates.io>.

  • cargo dist builds and uploads binary artifacts to the GH releases. This is triggered by creating a git tag CRATE_NAME_vMAJ.MIN.PATCH. Part of the normal PR CI cargo dist is also building artifacts and stores them as CI artifacts.

Since every crate in the workspace is currently having independent versioning it is not trivial to rely on "latest" release. This is explicitly harming publishing binary artifacts. As of now every crate is released in a separate tag with binary artifacts included in the corresponding release. Maybe combined tag (i.e. in a form YYYY-MM-DD) may be produced repackaging binaries, but it is not the case right now.