Implement GitHub Action to automate patches and documentation

[Pequod55]

Solution Overview:

This change introduces a new workflow to streamline the process of adding, updating, and documenting patches. The solution is summarized as:

• A single input file, modify_patchlist.yaml, is used to define new software and patches.
• A GitHub Action is triggered on Pull Requests, which automatically executes the update logic.
• A new Python script (.github/workflows/modify_patches.py) parses the input file, removes duplicate/older patch versions, and updates the primary Ansible configuration (roles/common/defaults/main.yml).
• A second Python script (.github/workflows/modify_documentation.py) updates the software download tables in the user guide (docs/user-guide.md).
• The automation is idempotent; it comments out processed entries in modify_patchlist.yaml to prevent re-runs.
• A Bash script (.github/workflows/commit_patches.bash) commits all automated changes back to the user's branch.
• Documentation is updated with a user and technical guide for the new process.

Test Commands:

The primary test is to follow the new user workflow. These steps simulate a user adding a new RDBMS patch.

Test Prep:

1. Ensure Python 3 and the pyyaml library are installed:

pip install pyyaml

2. Create and check out a new branch from master.
3. In the modify_patchlist.yaml file, add a new entry under the rdbms_patches section. For example:
   rdbms_patches:

  - { category: "RU", base: "21.3.0.0.0", release: "21.99.0.0.0", patchnum: "39999999", patchfile: "p39999999_210000_Linux-x86-64.zip", patch_subdir: "/", prereq_check: false, method: "opatch apply", ocm: false, upgrade: false, md5sum: "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" }

In the same file, add an override for the documentation under documentation_overrides:

documentation_overrides:
  rdbms_patches:
    category: "Test Patch - MOS"
    software_piece: "Database Release Update 21.99 (Test)"
    file_name: "p39999999_210000_Linux-x86-64.zip"

Test 1: Run the automation scripts locally

Simulate the GitHub Action by running the scripts in order to validate their logic.

1. Run the documentation modification script:

python .github/workflows/modify_documentation.py

2. Run the patch modification script:

python .github/workflows/modify_patches.py

Test 2: Run the full Git workflow (End-to-End Test)

This test validates the complete, automated process as it would run in a PR.

1. After completing Test Prep, commit the changes to modify_patchlist.yaml:

git add modify_patchlist.yaml
git commit -m "feat: Add test RDBMS patch 21.99"

2. Push the branch and create a Pull Request to master to trigger the "Modify Patches" GitHub Action. If PR is created on non-master branch, the action can be triggered manually.

Expected Results:

For Test 1 (Local Run):

• The script modify_documentation.py runs successfully and prints log messages indicating it inserted a new row into the documentation.
• The file docs/user-guide.md contains a new table row for "Database Release Update 21.99 (Test)".
• The script modify_patches.py runs successfully and prints log messages indicating it inserted a new RDBMS patch.
• The file roles/common/defaults/main.yml now contains the new 21.99.0.0.0 patch entry under the rdbms_patches list.

For Test 2 (PR Workflow):

• The "Modify Patches" GitHub Action completes successfully in the PR checks.
• A new commit authored by "GitHub Actions" with the message "automation: Update patch files" is added to the PR branch.
• This new commit contains the automated changes to roles/common/defaults/main.yml and docs/user-guide.md.
• The same commit also shows the rdbms_patches entry in modify_patchlist.yaml being commented out.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Pequod55
Once this PR has been reviewed and has the lgtm label, please assign alexbasinov for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[google-oss-prow]

Hi @Pequod55. Thanks for your PR.

I'm waiting for a google member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mfielding]

Is this a dupe of #343 ? If so, should we close this one?

[Pequod55]

@mfielding Apologies I forgot to close this PR, #343 is the simplified version with unit tests!