Docs: Add Conventional Commits Documentation #643
Conversation
| well-defined, change and are well-described. Otherwise multiple commits should | ||
| be squashed. | ||
|
|
||
| ### **Conventional Commits** |
There was a problem hiding this comment.
I think this should be one header level lower (####) since it's within the ### 4. Commit your changes step
There was a problem hiding this comment.
(also I don't think it should be bold, since there's no other bold headers in this doc)
There was a problem hiding this comment.
You're technically right. it should be #### since it's nested. However, when I first tried that, it felt a bit off because it didn’t make “conventional commit” stand out as a distinct topic, just regular text. What are your thoughts?
| Using multiple commits is allowed as long as they achieve an independent, | ||
| well-defined, change and are well-described. Otherwise multiple commits should | ||
| be squashed. | ||
| ### **Git Trailers** |
There was a problem hiding this comment.
I think this should be one header level lower (####) since it's within the ### 4. Commit your changes step
There was a problem hiding this comment.
(also I don't think it should be bold, since there's no other bold headers in this doc)
| - `Auth`: Authentication & Authorisation | ||
| - `Clients`: Client libraries and tools | ||
| - `Consistency`: Consistency checks | ||
| - `CI`: Continous Integration |
There was a problem hiding this comment.
This is not a separate component, it's under Testing (https://rucio.github.io/documentation/component_leads/)
There was a problem hiding this comment.
However, we frequently refactor our CI tooling without modifying any tests. Updates to GitHub Actions, pre-commit hooks, or CI jobs don’t affect the tests directly, so I thought it would make sense to have a separate component dedicated to changes in our GitHub CI infrastructure.
There was a problem hiding this comment.
I agree and I brought this up to the component leads last year, but the conclusion was that we would consider CI under Testing as the component leads would likely be the same for both components anyway. So I'm not sure overall, but I think if we want to maintain the 1:1 mapping between these labels and the components, we should stick to just Testing for now and then we can consider adding a CI component and adding a label for it later on
| - `DIRAC`: DIRAC integration | ||
| - `Docker`: Docker related functionality | ||
| - `Documentation`: Documentation updates | ||
| - `Kubernetes`: Kubernetes deployment related functionality |
There was a problem hiding this comment.
Docker and Kubernetes are part of a single component https://rucio.github.io/documentation/component_leads/ - I would also be in favour of maybe just calling it Containerization so that we don't have to use tool-specific names
| - `Rules`: Replication rules and rule daemons | ||
| - `Subscriptions`: Subscription daemon | ||
| - `Testing`: Regression and Unit tests | ||
| - `Traces`: Monitoring & Traces |
There was a problem hiding this comment.
Monitoring and traces are part of a single component https://rucio.github.io/documentation/component_leads/
There was a problem hiding this comment.
Should we call the component telemetry or observability, since Monitoring-Traces feels a bit too long for commit component naming?
There was a problem hiding this comment.
I think "monitoring" can probably be considered a superset of "traces" so monitoring on its own should be fine, but i like "observability" too. "Telemetry" has a negative connotation imo and it does not reflect what's being done here, so I would avoid using it
There was a problem hiding this comment.
(well, it reflects what's being done here, but we're not doing the kind of telemetry that is associated with negative connotations)
| - `Metadata`: Metadata workflows | ||
| - `Monitoring`: Monitoring and observability | ||
| - `MultiVO`: Multi-VO functionality | ||
| - `Opendata`: Open data functionality |
There was a problem hiding this comment.
In theory this is not a defined component at the moment https://rucio.github.io/documentation/component_leads/, but I think it makes sense that it would be a separate component. @bari12 what do you think?
There was a problem hiding this comment.
There’s already a GitHub label for Opendata, and since @lobis is actively working on it with commits referencing this component, I’ve added it as a component for the Conventional Commit format.
There was a problem hiding this comment.
I also agree this should be a distinct component.
A while back we agreed that the correct name to use would be Open Data or OpenData instead of Opendata, which I used when I first began working on the feature.
I have updated the label name to reflect this (to Open Data) and I guess the proper term in the commit messages should be OpenData.
| - `Rebalancing`: Data rebalancing | ||
| - `Recovery`: Data recovery | ||
| - `Replicas`: Replica workflows | ||
| - `REST`: REST & API |
There was a problem hiding this comment.
I would vote for API as component name here, rather than REST
| - `Metadata`: Metadata workflows | ||
| - `Monitoring`: Monitoring and observability | ||
| - `MultiVO`: Multi-VO functionality | ||
| - `Opendata`: Open data functionality |
There was a problem hiding this comment.
| - `Opendata`: Open data functionality | |
| - `OpenData`: Open data functionality |
I think this would be more consistent with CERN's usage of the term as discussed in the past.
There was a problem hiding this comment.
Technically, we would have to decide to add this as a component in Rucio first, which is probably a good idea :-)
There was a problem hiding this comment.
I am wondering, how would @lobis rebase his OpenData commits with other components? for the conventional commit CI. The CI would end up failing for him.
4 participants
Closes: #633