Releases and Publishing

Relevant source files

The following files were used as context for generating this wiki page:

• galaxy.yml
• CONTRIBUTING.md
• README.md
• roles/websphere/meta/main.yml
• roles/iim/meta/main.yml
• roles/weblogic/meta/main.yml

Releases and publishing for the spm_middleware project involve the packaging and distribution of Ansible content, including roles, modules, and playbooks. The project is structured as an Ansible Collection, which serves as a distribution format to enable the reuse of middleware installation suites required for Social Program Management (SPM).

The publishing workflow is primarily centered around Ansible Galaxy and GitHub, utilizing metadata defined in the root of the repository to control the build process and versioning. The system relies on semantic versioning and integration with CI/CD tools to automate the tagging and distribution of new versions to the merative namespace on Ansible Galaxy.

Sources: README.md:9-12, galaxy.yml:8-15

Collection Metadata and Configuration

The primary configuration for publishing the collection resides in the galaxy.yml file. This file contains the essential metadata required by Ansible Galaxy and other packaging tools to build the collection artifact.

Key Metadata Fields

The following table summarizes the core metadata used during the release process:

Field	Description	Source
namespace	The organization under which the content lives (merative).	galaxy.yml:5-6
name	The specific name of the collection (spm_middleware).	galaxy.yml:8-9
version	The semantic version of the collection (e.g., 1.8.8).	galaxy.yml:11-13
readme	Path to the Markdown documentation included in the release.	galaxy.yml:16
authors	List of contributors (SPM DevOps Team).	galaxy.yml:20-22
repository	The GitHub URL for the source code.	galaxy.yml:30

Build Exclusions

To ensure a clean release, the publishing process ignores specific development and testing directories. These are defined under the build_ignore key in galaxy.yml.

build_ignore:
  - molecule
  - skeleton_role
  - tests
  - runLint.sh
  - tagAndPublish.sh
  - scripts

Sources: galaxy.yml:35-41

Automated Publishing Workflow

The project utilizes environment variables to facilitate automated tagging and publishing, particularly when integrated with CI platforms like Travis CI or GitHub Actions.

Required Environment Variables

To enable release automation, the following variables must be configured:

• GITHUB_OAUTH_TOKEN: A GitHub Personal Access Token used for creating tags and publishing releases.
• ARTIFACTORY_TOKEN/URL/REPO: Credentials used if installers or artifacts are pulled from or pushed to a private Artifactory instance during the release validation phase.

Sources: CONTRIBUTING.md:154-159

Release Flow Logic

The following diagram illustrates the flow from code contribution to collection publication:

The workflow ensures that contributions meet minimum criteria (idempotency, Molecule tests, and Ansible linting) before they are eligible for publishing.
Sources: CONTRIBUTING.md:120-125, galaxy.yml:11-13

Role-Level Metadata

Each role within the collection (e.g., websphere, weblogic, iim, liberty) maintains its own meta/main.yml file. While galaxy.yml handles the collection-level release, these files define role-specific attributes that are visible when the collection is explored on Ansible Galaxy.

Role Metadata Structure

Roles define their own supported platforms and versions, which informs users about the compatibility of the released version.

• Platforms: Commonly supports "EL" (Enterprise Linux) versions 7, 8, or 9.
• Dependencies: Lists other roles required for the specific middleware component to function.
• License: Typically released under the MIT license.

Sources: roles/websphere/meta/main.yml:12-25, roles/weblogic/meta/main.yml:12-28, roles/iim/meta/main.yml:12-34

Summary of Publishing Requirements

Before a version is published, it must adhere to the project's contribution and quality standards to ensure stability for internal test and development environments.

1. Semantic Versioning: The version in galaxy.yml must be updated and should match the tags in GitHub.
2. Linting: The code must pass runLint.sh.
3. Testing: Molecule scenarios must pass for all supported platforms (e.g., Rocky Linux 8, CentOS 7).
4. Metadata Accuracy: galaxy.yml entries must point to correct locations for the README and repository links.

Sources: README.md:5-7, CONTRIBUTING.md:120-125, galaxy.yml:11-13