During the development of HarmonyOS Next, ohpm-repo, as a private repository management tool, its stable operation is crucial for the smooth progress of the project. Effective automated operation and maintenance is the key to ensuring the efficient operation of ohpm-repo, covering multiple aspects such as log management, repository backup and restoration, and batch operations. Next, we will discuss these automated operation and maintenance capabilities in detail.

How to Manage the Logs of ohpm-repo?

ohpm-repo has a built-in logger that defines four types of logs, namely access log (access.log), operation log (operate.log), running log (run.log), and running error log (repoError.log), and each type of log plays a unique role in operation and maintenance.

  • run.log: The running log records the key information during the operation of ohpm-repo, including the operation time, log level, and detailed log information. It can help us understand the working status of each module in the system during operation. For example, during the startup process, run.log will record the initialization status of each service. If a service fails to initialize, detailed error information will be recorded here, which is convenient for us to quickly locate the root cause of the problem. By analyzing run.log, we can promptly detect potential performance issues or system anomalies. For instance, if there are frequent records of loading delays of a certain functional module, it is necessary to further check the code or relevant configuration of that module.
  • access.log: The access log mainly includes information such as operation time, server IP, operation source, operation result, and the requested interface or static resource. By analyzing access.log, we can understand the access situation of users to the repository, such as which IP addresses frequently access the repository and what interfaces and resources are accessed. This helps us optimize the resource allocation of the repository and can also promptly detect abnormal access behaviors. For example, if an IP requests a large number of repository resources within a short period, it may be under a malicious attack, and corresponding security measures need to be taken at this time.
  • operate.log: The operation log records the operation time, log level, operator ID (userId), terminal IP (ip), operation resource (resource), operation method name (event), and operation result (result). The operation method names cover various operations such as login, publishing resource packages, and parsing uploaded packages. By checking operate.log, we can track the specific operations of users in the repository, which is convenient for auditing and troubleshooting. For example, when a package upload fails, we can view the detailed information of the upload operation in operate.log, including the uploader, upload time, operation resource, etc., to determine whether it is a user operation error or a system problem.

When actually analyzing the logs, we can filter the key information according to the log level. The printing levels of access, operation, and running logs can be set in the config.yaml configuration file, and the logs will only print the logs whose levels are not lower than the set level. The log levels from low to high are: all, trace, debug, info, warn, error, fatal, mark, and off. During the development and testing phases, the log level can be set to a lower level (such as debug) to obtain more detailed information; in the production environment, to avoid excessive log interference, the level is usually set to info or warn. At the same time, by combining with the timestamps of the logs, we can sort out the operation status of the system and user operations in chronological order, and locate and solve problems more efficiently.

How to Perform Repository Backup and Restoration?

ohpm-repo pack Generates Backup Files

The ohpm-repo pack command provided by ohpm-repo is used to generate repository backup files, which is a key step in repository backup. Before executing this command, it is necessary to ensure that the ohpm-repo service has been successfully started. The command format is ohpm-repo pack , where is the deployment directory of the ohpm-repo private repository.
For example:

ohpm-repo pack D:\ohpm-repo

After executing this command, if the data storage db module uses mysql, the command will only package all the contents of the conf and meta directories; if filedb is used, it will package all the contents of the conf, db, and meta directories. During the packaging process, the ohpm-repo service will first be set to read-only mode, and then reset to read-write mode after the packaging is completed. The generated backup files can be used for subsequent repository restoration operations to ensure that data and services can be quickly restored in case of data loss or system failure.

ohpm-repo deploy for Restoration

When it is necessary to restore the repository, we use the ohpm-repo deploy command. The prerequisite is to have obtained the .zip file packaged by the pack command. The command format is ohpm-repo deploy [options], where specifies the path of the packaged product.
For example:

ohpm-repo deploy D:\ohpm-repo\bin\pack_1695805599689.zip --deploy_root D:\new-ohpmrepo\ohpm-repo-deploy

This command will use the specified packaged file to replace the corresponding files in the ohpm-repo deployment root directory , and then restart the ohpm-repo service. During the execution process, it will check whether the list of ohpm-repo instances stored in the mysql database is consistent with the list of ohpm-repo instances in the configured sftp storage directory. If they are inconsistent, the command execution will fail. In addition, more refined control over the deployment process can be achieved through command options, such as --deploy_root to specify the deployment directory, --logs to specify the log directory, --uplinkCachePath to specify the remote package cache path, etc. These options can be flexibly configured according to actual needs to ensure that the restoration process meets the requirements of the actual environment.

Automated Operation and Maintenance: How to Batch Download, Upload, and Check Storage Integrity?

batch_download for Batch Download

The ohpm-repo batch_download command is used to batch download package files from ohpm-repo or the OpenHarmony third-party library central repository and export them as zip files. The prerequisite for executing this command is that the export_pkginfo command has been successfully executed to generate the pkgInfo_xxx.json file. The command format is ohpm-repo batch_download , where specifies the json file exported by executing the export_pkginfo command.
For example:

ohpm-repo batch_download

If you want to download package files from the OpenHarmony third-party library central repository, you can also use the --public-registry option to specify the registry address of the central repository and the --http-proxy option to set the proxy. This command greatly improves the efficiency of downloading multiple packages. Especially when a project depends on a large number of third-party libraries, all the required packages can be downloaded through one operation, saving a lot of time and effort. The generated zip file contains a pkgInfo.json file that records the key information of each package, which is convenient for subsequent batch upload operations.

batch_publish for Batch Upload

The ohpm-repo batch_publish command is used to batch upload the packages in the provided zip file to ohpm-repo. The command format is ohpm-repo batch_publish , where specifies the zip file exported by executing the batch_download command.
For example:

ohpm-repo batch_publish

If the organization of a package does not exist in ohpm-repo during batch upload, the --force option can be used, and the system will select an administrator user as the organization leader to automatically create the organization. This command, used in conjunction with the batch_download command, realizes the rapid migration and deployment of packages between different repository environments, improving the deployment efficiency of the project.

check_storage to Check Storage Integrity

The ohpm-repo check_storage command is used to check the integrity of the packages stored in sftp. The prerequisite for executing this command is that the ohpm-repo service has been successfully started, the type of the data storage db module is mysql, and the type of the file storage store module is sftp. The command format is ohpm-repo check_storage [options], where specifies the package to be checked or @all can be used to specify checking all packages.
For example:

ohpm-repo check_storage @ohos/basic-ftp

If you only want to check the packages that have not been processed in the download error log and meet the condition, you can use the --failed option. By regularly executing this command, we can ensure that the packages stored in sftp are complete and available, avoiding problems such as project build failures caused by package damage, and ensuring the reliability of the resources in the repository.

By reasonably using the automated operation and maintenance capabilities of ohpm-repo, such as log management, repository backup and restoration, and batch operations, we can manage the ohpm-repo private repository more efficiently and ensure the stable operation of the HarmonyOS Next development project. In the actual operation and maintenance process, according to the specific needs and scale of the project, flexibly combining and using these tools and commands can greatly improve the development efficiency and the reliability of the system.