Repositories overview #1295
Repositories overview #1295
Conversation
Thank you for contributing to the Leapp project!Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build.
Note that first time contributors cannot run tests automatically - they need to be started by a reviewer. It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported,
See other labels for particular jobs defined in the Please open ticket in case you experience technical problem with the CI. (RH internal only) Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra. |
| - **Use Existing Tags When Appropriate**: | ||
| - When creating new actors, consider using existing tags (such as PreUpgrade, PostUpgrade, etc.) | ||
| to categorize when the actor should be executed during the upgrade. |
There was a problem hiding this comment.
I would drop this. this is something what i would keep on other tutorials - e.g. how to create actor. also, there are no such tags. I would focus here just on stuff related to Where questions. Instructions about what tags should be used in actors should be rather covered by tutorials focused on creation of actors.
| @@ -0,0 +1,48 @@ | |||
| # Repositories Overview | |||
|
|
|||
| The **Leapp** project uses a modular repository structure in `repos/system_upgrade` to support multiple upgrade paths | |||
There was a problem hiding this comment.
| The **Leapp** project uses a modular repository structure in `repos/system_upgrade` to support multiple upgrade paths | |
| This project uses a modular repository structure in `repos/system_upgrade` to support multiple upgrade paths |
Well, I would not speak here about how the leapp framework works. The leapp project is reference actually to the leapp git repository and so to the framework or tooling. In this case, we could speak more e.g. about the upgrade project unless we add in future more stuff unrelated to the upgrade. So far, there is no such expectation so saying the upgrade project would work too.
|
|
||
| The **Leapp Project** provides the framework for automating in-place upgrades from one major version of Red Hat Enterprise Linux to another. It is organized into a set of modular components, each responsible for specific tasks during the upgrade process. These components are managed across multiple **repos**, logically grouped to facilitate upgrades between different RHEL paths. | ||
|
|
||
| This documentation explains the structure of the **Leapp repository** and provides guidance on how to determine where to place new entities, such as actors, models, and libraries, within the project. |
There was a problem hiding this comment.
| This documentation explains the structure of the **Leapp repository** and provides guidance on how to determine where to place new entities, such as actors, models, and libraries, within the project. | |
| This documentation explains the structure of this git repository and provides guidance on how to determine where to place new entities, such as actors, models, and libraries, within the project. |
Well, the name is not the best one, but we have to live with it. Phrase the leapp repository would be speaking in current terminology about one specific leapp repository (e.g. system_upgrade_el7toel8) or the actual leapp git repositoriy. So let's use either
- of this project
- of this git repository
- of the leapp-repository git repository
| @@ -1,6 +1,9 @@ | |||
| Project structure | |||
| ================= | |||
| TBD | |||
|
|
|||
| The **Leapp Project** provides the framework for automating in-place upgrades from one major version of Red Hat Enterprise Linux to another. It is organized into a set of modular components, each responsible for specific tasks during the upgrade process. These components are managed across multiple **repos**, logically grouped to facilitate upgrades between different RHEL paths. | |||
There was a problem hiding this comment.
Well, I would not speak about the leapp project as again that's a different repository. Leapp can be used also for different purposes and as it is, it does not know anywhine about upgrades at all. That's one of reasons why these two projects / repositories are separated. This (upgrade) project is just using the leapp framework and tooling to achieve the goal.
| - **`repos/system_upgrade/common/`**: Contains shared code that applies to all in-place upgrades, | ||
| regardless of the specific source and target versions. | ||
| - **`repos/system_upgrade/elXtoelY/`**: Contains code specific to concrete upgrade path. |
There was a problem hiding this comment.
the upgrade path is usually understood as X.Y -> X1.Y1, where elXtoelY coveres all upgrade paths from X to Y. I would consider it ok, but some people could be confused by different wording / meaining in different parts of the documentation (and official RH docs). So instead of speaking about upgrade path, I would rather say something like:
| - **`repos/system_upgrade/common/`**: Contains shared code that applies to all in-place upgrades, | |
| regardless of the specific source and target versions. | |
| - **`repos/system_upgrade/elXtoelY/`**: Contains code specific to concrete upgrade path. | |
| - **`repos/system_upgrade/common/`**: Contains shared code that applies to all in-place upgrades, | |
| regardless of the specific source and target versions. | |
| - **`repos/system_upgrade/elXtoelY/`**: Contains code specific for in-place upgrades between EL X and EL Y systems. |
Note that we do not want to use esplicitely RHEL in upstream documentation, as we would like to cover in future also CentoStream, and other forks using this project handles additional distributions. So going this more generic way seems to me better.
| - **Classify by Type**: | ||
| - Actor: If you’re creating an actor, | ||
| place it in the actors/ directory of the appropriate repository (version-specific or common). | ||
| - Model: If it’s a data structure shared between actors, place it in the models/ directory of the relevant repository. | ||
| - Library: Utility functions that support actors go in the libraries/ directory. |
There was a problem hiding this comment.
Not sure whether to keep this part. This is something what is generic and seems to me like something that should be covered by the leapp documentation. It's not possible to put an actor e.g. into models directory, etc. Models are always shared between actors. However, when speaking about libraries, it's a question whether it should be an actor's private library or shared library inside a specific leapp repository. But not sure whether to cover this one specific case in this particular section.
|
|
||
| Using changes in the Leapp repositories to perform an in-place upgrade involves modifying or adding new actors, models, | ||
| and workflows, building the modified repository, and using the Leapp tool to execute the upgrade. After integrating your changes, the upgrade process runs seamlessly with the customizations you've added, | ||
| ensuring the system is upgraded according to your specifications. |
There was a problem hiding this comment.
Thinking about this, it seems it's an information that should be presented in best-practices or something like that. This part of docs should cover the structure of this project, so it seems to me as out of the contect or scope of this part.
PR based on Docathon
Covers project structure > repositories