Support to patterns in an external repository

Release v1.9.0

Support to patterns in an external repository

---

Merged PR: #22
Author: @wesleycamargo

Multistage pattern template and Subscription scope pattern template

Release v1.8.0

Multistage pattern template and Subscription scope pattern template

---

Merged PR: #21
Author: @wesleycamargo

Built in deployment patterns

Release v1.7.0

Built in deployment patterns

---

Merged PR: #20
Author: @wesleycamargo

Fixed resource group scope deployment

Release v1.6.0

---

Merged PR: #19
Author: @wesleycamargo

Renaming the release engine repository

Release v1.5.0

Renaming the release engine repository

---

Merged PR: #18
Author: @wesleycamargo

Implement automated release management CI/CD pipeline

Release v1.4.0

Overview

This PR implements a complete CI/CD pipeline for automated release management in the release-engine-core repository. The workflow automatically creates semantic versioned releases when pull requests are merged into the main branch.

What's Included

GitHub Actions Workflow

A new workflow (.github/workflows/release.yml) that:

• Triggers automatically when a PR is merged to main
• Determines version bumps based on PR labels using semantic versioning
• Creates and pushes Git tags automatically
• Generates GitHub releases with PR title and description as release notes
• Includes metadata such as merged PR number and author in release notes

Semantic Versioning Logic

The workflow implements intelligent version management:

• Detects the latest existing tag (or starts from v0.0.0 if none exist)
• Reads PR labels to determine bump type:
  • major label → Breaking changes (e.g., v1.2.3 → v2.0.0)
  • minor label → New features (e.g., v1.2.3 → v1.3.0)
  • patch label → Bug fixes (e.g., v1.2.3 → v1.2.4)
  • bug label → Bug fixes (e.g., v1.2.3 → v1.2.4, treated as patch bump)
  • No label → Defaults to minor bump
• Follows semantic versioning specification strictly
• Handles edge cases (no existing tags, multi-digit versions)

Usage Example

For Contributors:

1. Create a PR with your changes
2. Add a version label: `major`, `minor`, `patch`, or `bug`
3. Write a clear PR title and description
4. Merge the PR to main
5. Workflow runs automatically and creates the release

Example PR:

• Title: "Add support for multi-region deployments"
• Label: minor (or no label)
• Result: Creates release v1.3.0 (from v1.2.5) with PR title and description

Example Bug Fix PR:

• Title: "Fix authentication timeout issue"
• Label: bug
• Result: Creates release v1.2.6 (from v1.2.5) with PR title and description

Documentation

Comprehensive documentation has been added:

• AUTOMATED-RELEASE-MANAGEMENT.md - Complete guide covering workflow behavior, usage instructions, troubleshooting, and examples
• RELEASE-QUICK-REFERENCE.md - Quick lookup for common tasks and label management
• Updated main README and docs README with links to the new documentation

Security & Testing

• ✅ CodeQL scan: 0 security vulnerabilities detected
• ✅ YAML validation: Syntax verified
• ✅ Logic testing: Version calculation and label detection tested (all tests passed)
• ✅ Minimal permissions: Only contents:write and pull-requests:read
• ✅ No secrets exposed: Uses built-in GITHUB_TOKEN
• ✅ Official actions: Uses actions/checkout@v4 and GitHub CLI

Implementation Details

Workflow Steps

1. Checkout repository with full history (fetch-depth: 0)
2. Get latest tag using git tag -l "v*" | sort -V
3. Determine version bump by parsing PR labels
4. Calculate new version using shell arithmetic
5. Create and push tag with git tag -a and git push
6. Create GitHub release using gh release create with PR metadata

Design Decisions

• Modern tooling: Uses gh CLI instead of deprecated actions/create-release@v1
• Flexible defaults: Defaults to minor bump if no label specified (promoting feature development as the primary workflow)
• Bug label support: Automatically treats PRs with bug label as patch version bumps
• Clear precedence: major > minor > patch > bug > default (minor) when multiple labels exist
• Rich metadata: Includes PR number and author in release notes
• Zero configuration: Works out of the box, no additional setup required

Breaking Changes

None. This is a new feature addition.

Testing Recommendations

Before merging, ensure the following labels exist in the repository:

gh label create major --description "Major version bump (breaking changes)" --color "d73a4a"
gh label create minor --description "Minor version bump (new features)" --color "0075ca"
gh label create patch --description "Patch version bump (bug fixes)" --color "cfd3d7"
gh label create bug --description "Bug fix (patch version bump)" --color "d73a4a"

When this PR is merged to main, it will trigger the first automated release!

Related Issues

Closes #[issue-number]

<issue_title>Create CI/CD pipeline for automated release management</issue_title>
><issue_description>## Overview
> Implement a CI/CD pipeline for the release-engine-core repository to automate release creation upon merging pull requests into main.
>
> ## Requirements
> - The pipeline should automatically trigger when a pull request is merged into the main branch.
> - After merging, the pipeline must:
> 1. Check the latest tag on the repository.
> 2. Increment the version according to semantic versioning (major/minor/patch), based on changes, and Pull Request labels.
> 3. Create a new tag in GitHub for the release.
> 4. Create a GitHub release using the new tag.
> 5. Set the release name and description using the merged pull request's title and description.
>
> ## Acceptance Criteria
> - CI/CD workflow is defined (e.g., GitHub Actions or other supported tool) and committed in the repository.
> - The workflow triggers only on merges to main.
> - Tag and release management follows semantic versioning automatically.
> - Release metadata (name and description) are sourced from the merged pull request.
>
> ## Notes
> - Ensure proper permissions for tag and release creation.
> - The workflow should be documented for maintainers.
>
> ---
> If additional input is needed (e.g., version bump logic), please specify in a follow-up issue or comment.</issue_description>
>
> ## Comments on the Issue (you are @copilot in this section)
>
>
>
>

Fixes #16

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Create CI/CD pipeline for automated release management</issue_title>
<issue_description>## Overview
Implement a CI/CD pipeline for the release-engine-core repository to automate release creation upon merging pull requests into main.

Requirements

• The pipeline should automatically trigger when a pull request is merged into the main branch.
• After merging, the pipeline must:
  1. Check the latest tag on the repository.
  2. Increment the version according to semantic versioning (major/minor/patch), based on changes, and Pull Request labels.
  3. Create a new tag in GitHub for the release.
  4. Create a GitHub release using the new tag.
  5. Set the release name and description using the merged pull request's title and description.

Acceptance Criteria

• CI/CD workflow is defined (e.g., GitHub Actions or other supported tool) and committed in the repository.
• The workflow triggers only on merges to main.
• Tag and release management follows semantic versioning automatically.
• Release metadata (name and description) are sourced from the merged pull request.

Notes

• Ensure proper permissions for tag and release creation.
• The workflow should be documented for maintainers.

---

If additional input is needed (e.g., version bump logic), please specify in a follow-up issue or comment.</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #16

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

---

Merged PR: #17
Author: @Copilot

v1.3.0

Multi-staging and multi-environment deployment

What's Changed

• Multi-staging and multi-environment deployment by @wesleycamargo in #13

Full Changelog: v1.2.0...v1.3.0

v1.2.0

Sequential environment deployments

Simplified required variables

Simplified required variables

Tokenization by environment variables

Tokenization by environment variables