Move SOP for new repos to more fleshed out repository-structure doc#137
Move SOP for new repos to more fleshed out repository-structure doc#137cgwalters wants to merge 1 commit intobootc-dev:mainfrom
Conversation
We want to describe the desired state, not just the steps for new repos. In particular a goal here is to flesh out how CI/testing should work and lean into the pattern that our projects should provide integration tests and how those should work. Signed-off-by: Colin Walters <walters@verbum.org>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refactors the organization's documentation for new repositories, transitioning from a step-by-step Standard Operating Procedure to a more holistic guide on desired repository structure and standards. The primary goal is to provide a clearer vision for how projects should be organized, with a particular emphasis on robust CI/testing practices and standardized integration test methodologies. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request effectively refactors the new repository SOP into a more comprehensive repository-structure.md document. The new document is well-structured and expands on important topics like CI/testing, which was a stated goal. I've left a few minor suggestions in docs/repository-structure.md to fix a typo and improve clarity and consistency. Overall, this is a great improvement to the organization's documentation.
| # Repository structure | ||
|
|
||
| The bootc-dev organization contains a number of repositories. While not every | ||
| repository will function in exactly in the same way, there are |
There was a problem hiding this comment.
There's a small typo here; the word "in" is repeated.
| repository will function in exactly in the same way, there are | |
| repository will function in exactly the same way, there are |
| There should be a `maintainers` team with the **Maintain** permission | ||
| that is used by repositories by default. |
There was a problem hiding this comment.
This phrasing is a bit ambiguous. The previous documentation was more direct. To make this a clear and enforceable standard, consider using stronger language like MUST for consistency with other rules in this document.
| There should be a `maintainers` team with the **Maintain** permission | |
| that is used by repositories by default. | |
| All repositories MUST grant the `maintainers` team the **Maintain** permission. |
| part of a simple single binary. | ||
|
|
||
| - [composefs-rs](https://github.com/composefs/composefs-rs/tree/main/crates/integration-tests) | ||
| - [bcvk](https://github.com/bootc-dev/bcvk/blob/main/Justfile) |
There was a problem hiding this comment.
The examples provided to illustrate the libtest-mimic pattern are a bit inconsistent. The link for composefs-rs points to the integration test source code, while the link for bcvk points to its Justfile. For better clarity and consistency, consider updating the bcvk link to point directly to its integration test source directory, similar to the composefs-rs example.
SNThrailkill
left a comment
SNThrailkill
left a comment
There was a problem hiding this comment.
Very happy to get some standardization on this
| - Custom managers for Containerfiles and txt files | ||
| - Disabled Fedora OCI updates and digest pinning | ||
|
|
||
| ### Repository-Specific Overrides |
There was a problem hiding this comment.
Hi @cgwalters , do we need keep this section in repository-structure.md?
There was a problem hiding this comment.
I want to get rid of syncing GHA via sync-common and move everything to use bootc-dev/actions so that bit becomes obsolete.
3 participants
We want to describe the desired state, not just the steps for new repos.
In particular a goal here is to flesh out how CI/testing should work and lean into the pattern that our projects should provide integration tests and how those should work.