Removed release process from contributor guidelines (#167)
This commit is contained in:
Chris Edillon
GitHub
12
CHANGELOG.md
12
CHANGELOG.md
@@ -1,12 +0,0 @@
|
|||||||
# Changelog
|
|
||||||
|
|
||||||
All notable changes to this project will be documented in this file.
|
|
||||||
|
|
||||||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
|
||||||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
||||||
|
|
||||||
## [v-0.0.1](https://github.com/ansible/product-demos/-/tree/v-0.0.1) - 2024-01-12
|
|
||||||
|
|
||||||
### Added
|
|
||||||
|
|
||||||
- Initial release ([1af584b4ea6d77812bfcb2f6474fee6ee1b13666](https://github.com/ansible/product-demos/-/commit/1af584b4ea6d77812bfcb2f6474fee6ee1b13666))
|
|
||||||
@@ -18,6 +18,7 @@ This document aims to outline the requirements for the various forms of contribu
|
|||||||
- PRs should be rebased against the `main` branch to avoid conflicts.
|
- PRs should be rebased against the `main` branch to avoid conflicts.
|
||||||
- PRs should not impact more than a single directory/demo section.
|
- PRs should not impact more than a single directory/demo section.
|
||||||
- PRs should not rely on external infrastructure or configuration unless the dependency is automated or specified in the `user_message` of `setup.yml`.
|
- PRs should not rely on external infrastructure or configuration unless the dependency is automated or specified in the `user_message` of `setup.yml`.
|
||||||
|
- PR titles should describe the work done in the PR. Titles should not be generic ("Added new demo") and should not refer to an issue number ("Fix for issue #123").
|
||||||
|
|
||||||
## Adding a New Demo
|
## Adding a New Demo
|
||||||
1) Create a new branch based on main. (eg. `git checkout -b <branch name>`)
|
1) Create a new branch based on main. (eg. `git checkout -b <branch name>`)
|
||||||
@@ -31,7 +32,7 @@ This document aims to outline the requirements for the various forms of contribu
|
|||||||
1) You can copy paste an existing one and edit it.
|
1) You can copy paste an existing one and edit it.
|
||||||
2) Ensure you edit the name, playbook path, survey etc.
|
2) Ensure you edit the name, playbook path, survey etc.
|
||||||
5) Add any needed roles/collections to the [requirements.yml](/collections/requirements.yml)
|
5) Add any needed roles/collections to the [requirements.yml](/collections/requirements.yml)
|
||||||
6) Test via [demo.redhat.com](https://demo.redhat.com/catalog?item=babylon-catalog-prod/sandboxes-gpte.aap-product-demos.prod&utm_source=webapp&utm_medium=share-link), specify your branch name within the project configuration.
|
6) Test via [demo.redhat.com](https://demo.redhat.com/catalog?search=product&item=babylon-catalog-prod%2Fopenshift-cnv.aap-product-demos-cnv.prod), specifying your branch name within the project configuration.
|
||||||
|
|
||||||
> NOTE: demo.redhat.com is available to Red Hat Associates and Partners with a valid account.
|
> NOTE: demo.redhat.com is available to Red Hat Associates and Partners with a valid account.
|
||||||
|
|
||||||
@@ -43,13 +44,10 @@ This document aims to outline the requirements for the various forms of contribu
|
|||||||
---
|
---
|
||||||
user_message: ''
|
user_message: ''
|
||||||
|
|
||||||
controller_components:
|
|
||||||
- job_templates
|
|
||||||
|
|
||||||
controller_templates:
|
controller_templates:
|
||||||
...
|
...
|
||||||
```
|
```
|
||||||
- `controller_components` can be any of the roles defined [here](https://github.com/redhat-cop/controller_configuration/tree/devel/roles)
|
- Configuration variables can be from any of the roles defined in the [infra.controller_configuration collection](https://github.com/redhat-cop/controller_configuration/tree/devel/roles)
|
||||||
- Add variables for each component listed
|
- Add variables for each component listed
|
||||||
3) Include a README.md in the subdirectory
|
3) Include a README.md in the subdirectory
|
||||||
|
|
||||||
@@ -72,76 +70,3 @@ Copy the token value and execute the following command:
|
|||||||
```bash
|
```bash
|
||||||
export ANSIBLE_GALAXY_SERVER_AH_TOKEN=<token>
|
export ANSIBLE_GALAXY_SERVER_AH_TOKEN=<token>
|
||||||
```
|
```
|
||||||
|
|
||||||
## Release Process
|
|
||||||
|
|
||||||
We follow a structured release process for this project. Here are the steps involved:
|
|
||||||
|
|
||||||
1. **Create a Release Branch:**
|
|
||||||
- Start by creating a new release branch from the `main` branch.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git checkout -b release/v-<version>
|
|
||||||
```
|
|
||||||
|
|
||||||
2. **Update Changelog:**
|
|
||||||
- Open the `CHANGELOG.md` file to manually add your change to the appropriate section.
|
|
||||||
- Our changelog follows the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format and includes the following categories of changes:
|
|
||||||
|
|
||||||
- `Added` for new features.
|
|
||||||
- `Changed` for changes in existing functionality.
|
|
||||||
- `Deprecated` for features that will be removed in upcoming releases.
|
|
||||||
- `Fixed` for bug fixes.
|
|
||||||
- `Removed` for deprecated features that were removed.
|
|
||||||
- `Security` for security-related changes.
|
|
||||||
|
|
||||||
- Add a new entry under the relevant category. Include a brief summary of the change and the merge request commit tag.
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## [Unreleased]
|
|
||||||
|
|
||||||
### Added
|
|
||||||
|
|
||||||
- New feature or enhancement ([Merge Request Commit](https://github.com/ansible/product-demos/-/commit/<commit-hash>))
|
|
||||||
```
|
|
||||||
|
|
||||||
- Replace `<commit-hash>` with the actual commit hash from the merge request.
|
|
||||||
|
|
||||||
3. **Commit Changes:**
|
|
||||||
- Commit the changes made to the `CHANGELOG.md` file.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git add CHANGELOG.md
|
|
||||||
git commit -m "Update CHANGELOG for release <version>"
|
|
||||||
```
|
|
||||||
|
|
||||||
4. **Create a Pull Request:**
|
|
||||||
- Open a pull request from the release branch to the `main` branch.
|
|
||||||
|
|
||||||
5. **Review and Merge:**
|
|
||||||
- Review the pull request and merge it into the `main` branch.
|
|
||||||
|
|
||||||
6. **Tag the Release:**
|
|
||||||
- Once the pull request is merged, tag the release with the version number.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git tag -a v-<version> -m "Release <version>"
|
|
||||||
git push origin v-<version>
|
|
||||||
```
|
|
||||||
|
|
||||||
7. **Publish the Release:**
|
|
||||||
- After the successful completion of the pull request and merging into the `main` branch, an automatic GitHub Action will be triggered to publish the release.
|
|
||||||
|
|
||||||
The GitHub Action will perform the following steps:
|
|
||||||
- Parse the `CHANGELOG.md` file.
|
|
||||||
- Generate a release note based on the changes.
|
|
||||||
- Attach relevant files (such as `LICENSE`, `CHANGELOG.md`, and the generated `CHANGELOG.txt`) to the GitHub Release.
|
|
||||||
|
|
||||||
No manual intervention is required for this step; the GitHub Action will handle the release process automatically.
|
|
||||||
|
|
||||||
8. **Cleanup:**
|
|
||||||
- Delete the release branch.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git branch -d release/v-<version>
|
|
||||||
```
|
|
||||||
|
|||||||
Reference in New Issue
Block a user