--- tags: wp2 title: Final developer guidelines --- # Final developer guidelines - [x] **Introduction**: what we are going to explain in the next chapters (let's put focus on our own workflows, thus that we have created them starting from the developer needs and how they have been practically implemented through the GitHub Actions CI and applied to the WP6's project called `libp2p-rust-dht`) - [ ] **Software quality guidelines**: explaining what are the main and most used guidelines for open-source projects with regards to the evaluation of software and code quality. Let's start from a practical view, not an academic one. A single section for each part that composes a workflow (reuse, static analysis, dependencies, dynamic analysis, fuzzing). An additional section about deployment too. **Code certification** will be added to the code coverage part. Code coverage mechanism into the weighted code coverage part. - [ ] **GitHub Actions**: How our workflows have been implemented through GitHub Actions. The concepts of actions, jobs, steps and matrix. How they run and work with self-hosted machines. - [ ] **Rust example**: Explaining how GitHub Actions scripts have been inserted into a WP6 project called `rust-dht`. We have chosen this project because it has been effectively used in the pilot that represents SIFIS-Home architectures. We have to describe the entire procedure as a story. Also we need to explain why we have chosen Rust: - Because of its own characteristics (already explained in preliminary) - Because it has been widely used in SIFIS for components - Because it allows to cover different aspects of the defined workflows on each of the most famous three architectures (Linux, MacOS and Windows). Let's put focus on the fact that we have added the workflows for the three architectures and that static analysis and lints worked well, but during the development it was necessary to add an external library, easily manageable only from Linux, we have decided to maintain checks only for linux architecture not to waste CI resources. - Because C/C++ hasn't been used in SIFIS. - Because the other languages make use of an interpreter or do not need cross-platforms code and compilation, so it's better to show how we have handled those cases - Because we can show how a software is deployed - [ ] **Tools history**: Explain how we have found the tools used for our workflows. For what concerns the contribution to other tools and our own tools instead, such as WCC, we are going to explain how they work and the story of their implementation in the tools deliverable.