RFC: Sealer Makefile optimization

Problem

Currently, Sealer lacks a clear and consistent structure, making it difficult for developers to work with and improve. In addition, the GitHub actions workflow needs to be optimized and automated for increased efficiency. This process will help me become more familiar with the Sealer runtime and system design.

The following order of priority is based on our design goals 🎯

RFC:

Improve Makefile Structure

• Improve Makefile structure

We propose the following Makefile structure improvements, sorted by priority:

1. Implement optional copyright check (if not already implemented by actions).
2. Automatically parse help information for all makefile options.
3. Ensure consistent behavior, such as enforcing commit guidelines.
4. Add necessary options, such as unit test coverage (which we care about but currently do not provide).
5. Add debug information and selective debugging. Also, consider providing options to selectively generate binaries via sealer or seautil to improve compile speed.
6. Simplify the /Makefile module for readability.
7. The makefile provides cross-compilation
8. The Makefile docker-in-docker does not fully support amd/arm

Optimize GitHub Actions Workflow

• Optimize directory structure

The following changes will be made to optimize the GitHub Actions workflow:

1. Provide and automate CHANGELOG management.
2. Add automation for micro-operations and functionality not currently covered.

Directory Design

• Optimize actions workflow

Script Directory: We recommend migrating the /hack directory to the /script directory and moving the Makefile portion of the backend implementation to the script/make-rules directory.

CMD Commands: Sealer's commands are increasing in number, especially with alpha extensions. We propose extracting the core of the cmd to the /internal directory (only internally accessible) and /pkg directory (allowing for calls). We recommend moving the /common directory to the /pkg directory.

Version Information: We propose creating separate versions for Sealer system information (git information, Go information, etc.) and pkg runtime. Which directory should the two versions be stored in /pkg/version, /utils/version, or separately? We suggest adjusting the application info to /pkg/version for external access and placing utils/version into the runtime k8s module, abstracting an interface for external access.

Improve Version Control

We propose creating separate versions for Sealer system information (git information, Go information, etc.) and pkg runtime. We suggest moving the core of Sealer's commands (especially alpha extensions) to the /internal directory (internal access only) and /pkg directory (allowing for calls). Additionally, we propose supplementing relevant documentation, such as version API and Makefile guidelines.

Version Interface Design Scheme

We will create a runtime layer to abstract the version layer interface and design the interface. We will extract the versions of k3s, k0s, and Kubernetes and call them from the above versions. They do not need to care which cluster runtime version is being called.

Other RFC

RFC: Supplement k3s implementation.

RFC: Sealer currently lacks the ability to control APP calls, and Pack can help solve this problem. I will research buildpacks and refer to the official documentation of buildpacks.io.

We will provide Pack with the ability to build the upper-level Makefile abstractly, making it easier to build images. If Sealer can package and distribute clusters, it will have a very powerful ability.

We believe that these changes will create a more organized and efficient structure for Sealer and improve its functionality. By implementing these changes, we can make Sealer a more user-friendly and efficient development tool.

Tasks