[Release][1.11.0] GA

[fernandofloresg]

Pending to add #1529 Known issues

Release Requirements Checklist

This checklist is a chronological ordering of the release tasks to complete for an IBM Ansible z/OS core collection. This template is for a GA release that will release to Ansible Automation Platform and Galaxy as well. If you are following this issue, note that the version number is subject to change based on the certification outcome.

By this point the stagging-v<version> had been code frozen and releases tasks must only be meta data related, for example, updating galaxy.yml, runtime.yml, generating module doc if needed, release notes etc.

You should be checking off each task as it completes.

General workflow

This a subsequent release (not a patch) thus these releases tasks will eventually be merged intomain and into dev to allow for the meta data updates to propagate as well as the release tag.

(1) Technical Writer Tasks

• Ensure all technical writer Git issues are resolved for this release

(2) Release Tasks for release-tasks-v<version> branch:

• Update galaxy.yml
• Update meta/runtime.yml
• Update meta/ibm_zos_core_meta.yml
• Update README.md
• Update .ansible-lint config such that galaxy.yml and build_ignore entries are in sync.
• Review copyrights are updated as needed, e.g. current year if changes are made
• Update the support matrix in docs/resources/releases_maintenance.rst to add the newest entry and the correct support dates & supported dependencies version for the release.
• Generate module docs (restructured text - RST) and check it into the release branch
  • ac --ac-module-doc --command html
• Add a change log summary fragment in the /changelog directory for this release:
  - Create a file called "v<major>.<minor>.<patch>_summary.yml", eg v1.6.0_summary.yml
  - Place it under ibm_zos_core/changelogs/fragments/
  - Add contents (update the date, don't go past the current day):

release_summary: |
  Release Date: '2023-06-23'
  This changelog describes all changes made to the modules and plugins included
  in this collection. The release date is the date the changelog is created.
  For additional details such as required dependencies and availability review
  the collections `release notes <https://ibm.github.io/z_ansible_collections_doc/ibm_zos_core/docs/source/release_notes.html>`__

• Generate CHANGELOG.rst
  • ac --ac-changelog --command lint
  • ac --ac-changelog --command release
    Optionally:
  • antsibull-changelog lint
  • antsibull-changelog release or antsibull-changelog release -v
• Create release notes (docs/source/release_notes.rst)
• Run markdown linter pymarkdownlnt scan README.md
  • Note: These are acceptable only:

    MD033: Inline HTML [Element: br] (no-inline-html)
    MD013: Line length [Expected: 80, Actual: 252] (line-length)
    

• Review all module source imports; ensure sure no new imports are subject to license discrepancies

(3) Quality assurance

• Run a Mend scan and check the results into the designated repository

• Run a Bandit scan and check the results into the designated repository

• Ansible-lint validation , manual step at the moment, choose from one of the below to run ansible-lint:

  • ./ac --ac-lint
  • ./ac --venv-start
    • ansible-lint -c .ansible-lint --profile production

• Sanity tests, use the pipeline option and choose to run only the sanity tests by checking ANSIBLE_TEST_ONLY which specifies only Ansible Certification tests and security scan run, meaning no functional tests run." As a backup option, you can use the ./ac tool with similar options ./ac --ac-sanity to run sanity.

• Run the galaxy importer (currently a manual step as its not part of the pipeline yet)

  • Check output log for any errors/issues. For success, look for the following msg:

     Collection loading complete
     Importer processing completed successfully
    

  • ./ac --ac-galaxy-importer
    optionally:
  • python -m galaxy_importer.main ibm-ibm_zos_core-<version>.tar.gz. You can perform this with commands:

    $ ./ac --venv-start
    $ python -m galaxy_importer.main ibm-ibm_zos_core-1.7.0.tar.gz
    

• Full pipeline regression at 100% success on either release-tasks-v<version> or stagging-v<version>:

  • Certify on minimally required IBM Open Enterprise SDK for Python
  • Certify on minimally required ZOAU
  • Certify on latestansible-core supported in Ansible Automation Platform
  • Ensure RUN_ALL_TESTS is selected

(5) Validation

• Build the image from staging-v<version> branch, unpack it up, inspect the contents. Ensure only the required files are contained in the package.
• Test collection quality with an upload to the IBM HCF development Galaxy Server by uploading the build from branch staging-v<version>. This first build test is to alert you to any issues that might need to be made before opening a pull request.

(6) GitHub

• Open a pull request for staging-v<version> against main.
• When the pull request has been approved, do not merge it, build the collection again and test the collection quality again with a new build from the reviewed staging-v<version> branch by uploading it to the Ansible development Galaxy Server. (Do not merge the pull request till after AAP and Galaxy success.)

(7) Release tasks (In this order)

• Upload to AAP, on success continue to the next step.
• Upload to Galaxy, on success continue to the next step.
• Merge pull request for staging-v<version> against main and DO NOT delete the staging-v<version> branch, you will need the staging-v<version> branch soon enough.
• Create a draft release in GitHub, for:
  • "Choose a tag", enter v<version>, eg v1.6.0
  • "Target" , enter main
  • "Release title" , enter release-v<version>, eg release-v1.6.0
  • "Describe this release", enter the contents created for doc/source/release_notes.rst, you may need to remove trailing _ from the RST you paste since the description is supposed to be Markdown.
• Publish the Github release draft, include the collection archive as part of the release.
• Open a Git issue in z_ansible_collections_doc to have Red Hat® Ansible Certified Content for IBM Z docs generated
• Push stagging-v<version> changes into dev to ensure any fixes and meta are propagated upstream. There are different ways to do this, I find a merge ends up complicating things because dev will have received an entire quarters of changes and now old changes are pushed upstream. Generally, when performing the release tasks from bullet (2), I commit each separately so that I can cherry pick them later.All that should change is metadata , eg galaxy.yml , release_notes.rst, etc, no source. In case there is a source change, separate commits makes it easy to cherry pick. Optionally (usually what i do), you can cherry pick the PR which will have by default squashed all the individual commits. For example, if you want to cherry-pick the squashed PR, get the commit id from the PR then perform the following commands:

  git checkout dev <-- check out dev since this is where we want to cherry-pick to
  git pull                 <-- pull the latest
  git checkout -b cherry-picked-170-into-dev <-- create a new branch
  git cherry-pick 472611  <-- cherry-pick the squashed PR 
  git push -u origin cherry-picked-170-into-dev <-- push the changes and then open a PR against dev
  

(8) Log collection

• Copy any additional playbook or manual tests performed into the release folder
• Copy the pipeline log from Jenkins into the release folder
• Copy the Automation Hub import log into the release folder
• Copy the Galaxy import log in the release folder
• Copy the git log (git log --pretty=oneline) into the release folder

[ddimatos]

ansible-lint known and accepted:

tests/sanity/ignore-2.15.txt:18: sanity[cannot-ignore]: Ignore file contains validate-modules:invalid-extension at line 18, which is not a permitted ignore.
tests/sanity/ignore-2.15.txt:19: sanity[cannot-ignore]: Ignore file contains validate-modules:python-syntax-error at line 19, which is not a permitted ignore.
tests/sanity/ignore-2.16.txt:18: sanity[cannot-ignore]: Ignore file contains validate-modules:invalid-extension at line 18, which is not a permitted ignore.
tests/sanity/ignore-2.16.txt:19: sanity[cannot-ignore]: Ignore file contains validate-modules:python-syntax-error at line 19, which is not a permitted ignore.
tests/sanity/ignore-2.17.txt:19: sanity[cannot-ignore]: Ignore file contains validate-modules:invalid-extension at line 19, which is not a permitted ignore.

[ddimatos]

Galaxy importer known and accepted:

WARNING: tests/sanity/ignore-2.15.txt:18: sanity[cannot-ignore]: Ignore file contains validate-modules:invalid-extension at line 18, which is not a permitted ignore.
WARNING: tests/sanity/ignore-2.15.txt:19: sanity[cannot-ignore]: Ignore file contains validate-modules:python-syntax-error at line 19, which is not a permitted ignore.
WARNING: tests/sanity/ignore-2.16.txt:18: sanity[cannot-ignore]: Ignore file contains validate-modules:invalid-extension at line 18, which is not a permitted ignore.
WARNING: tests/sanity/ignore-2.16.txt:19: sanity[cannot-ignore]: Ignore file contains validate-modules:python-syntax-error at line 19, which is not a permitted ignore.
WARNING: tests/sanity/ignore-2.17.txt:19: sanity[cannot-ignore]: Ignore file contains validate-modules:invalid-extension at line 19, which is not a permitted ignore.
...ansible-lint run complete
WARNING: Ignore files skip ansible-test sanity tests, found ignore-2.17.txt with 25 statement(s)
WARNING: Ignore files skip ansible-test sanity tests, found ignore-2.16.txt with 25 statement(s)
WARNING: Ignore files skip ansible-test sanity tests, found ignore-2.15.txt with 25 statement(s)