Auto Patch Signer
Introduction
Patch signing is a part of the patch developing process. Patch signing has main 2 parts, Patch validation and signing. There are 3 types of patches. Those are Patches, Updates and Patch and Updates. For Patches validation done by reading files in the patch zip file and for Updates validation done using WUM UC, For Patch and Updates should use both methods and validate Patch and Update separately. If validation is successful, then SVN Keys will be generated, committed and locked. Reverting of this process called patch reverting.
Auto patch signer developed for automated the patch validation and signing process as well as patch reverting. This system is an MSF4J micro-service. It has 2 main services, “sign” for patch validation and signing and “revert” for patch reverting. Sign service will be called in every 10 minutes using a cron and will sign and validate all the patches submitted by developers in the PMT. Revert service can be used to revert a particular patch by giving its patch name.
System Architecture
Artifact that needed to be deployed in License Text File Generation application. Micro-service related to patch validation, signing and revert.
Micro-service Structure
Auto patch signer microservice has 3 endpoints. “sign” is used to validate and sign patches. “revert” is used to revert signed patches and “addProduct” is used to add new product details to the database.
sign
This endpoint will invoke periodically every day. This will validate and sign all the patches in PMT in the “Ready to sign” state and after each patch, it will send a mail to the relevant developer about the status of the patch validation and signing and log errors to the database.
revert
This endpoint can be called by giving a patch name as a string parameter. It should be in “WSO2-CARBON-PATCH-4.4.0–1001” format. This service will update the PMT life cycle state to Testing, delete related entries from the WUM UAT database and unlock and delete SVN.
Database Structure
Auto patch signer uses two tables for data storage. One table for store data about WSO2 Inc. products and another one to keep records about error or success messages about patch validation, signing, updating PMT and reverting.
The ‘Product detail’ table contains details about all the WSO2 products and if some new product is releasing the user will insert details of that product to the table using Add product service.
Auto Patch Signing Process
- Developer submits the patch, update or patch and update to the PMT. The life cycle state of this patch will be changed to the “Ready to sign” state.
- Sign service will be called periodically every day and all the patches in the “Ready to sign” state will be retrieved from PMT.
- Micro-service will iterate this patches list one by one, get patch information for each from PMT, download the needed patch or update zip from SVN repository and then validate it with each and every WSO2 product in overview products field of patch information.
- If this WSO2 product is a new product, not available on the local server it will download it from Atuwa.
- These products in the local server will be updated by WUM every 24 hours.
- If the validation finished successfully, the micro-service will generate keys and commit to the WSO2 SVN repository.
- If committing to the SVN repository is successful, the patch life cycle in PMT will be updated based on patch type.
- Patch — Released, Released not automated, Released not in public svn
- Update — UAT staging
- Patch and Update — UAT staging
- End of signing micro-service will send an email to the relevant developer about the status of validation, signing and updating PMT or errors that occurred in the process.
- User can also revert the signing process using Auto patch signer. It will change the PMT life cycle state to “Testing”, Delete related entries from the WUM UAT database and WUM staging database and delete generated keys from WSO2 Inc. SVN repository.
