Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

udpate readme for Release Manager #976

Merged
merged 4 commits into from
Jan 18, 2024
Merged

udpate readme for Release Manager #976

merged 4 commits into from
Jan 18, 2024

Conversation

BraisVQ
Copy link
Contributor

@BraisVQ BraisVQ commented Dec 11, 2023

Closes #969 and #974

release-manager/files/README.md Outdated Show resolved Hide resolved
release-manager/files/README.md Outdated Show resolved Hide resolved
release-manager/files/README.md Outdated Show resolved Hide resolved
release-manager/files/README.md Show resolved Hide resolved
release-manager/files/README.md Outdated Show resolved Hide resolved
- When no `version` is given, the orchestration pipeline will default to `WIP` (work in progress). In this scenario, source code for each repository is taken from the configured branch in the `metadata.yml` file (defaulting to `master` if no branch is specified there).
- When a `version` is given, source code will be taken from a branch `release/$VERSION` in each repository. When this branch does not exist yet, it will be created (based on the configured branch in `metadata.yml`) by the pipeline. Subsequent runs with the same `version` input will take the source code from the created release branch - changes to the configured branch will have no effect on this version! This is by design: it allows some developers to work on new features on the mainline branch (typically `master`) while others polish the release branch. To this end, the orchestration pipeline allows to enable separate development environments per version to isolate changes in OpenShift resources (see section "Environments" further down).
- The orchestration pipeline applies the same branching rules to the release manager repository - it will create a release branch per version. There is one small caveat here: Jenkins only considers the `Jenkinsfile` from the branch which is configured for a pipeline. That means that for a pipeline setup against `master`, Jenkins will always execute the latest `Jenkinsfile` from `master`, even when you pass an explicit `version` to the pipeline. The orchestration pipeline will read e.g. the `metadata.yml` file from the matching release branch, but the `Jenkinsfile` itself will be from `master`. Usually, this should not be an issue as you should not make changes to the `Jenkinsfile` of the release manager repository anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this section could be backed by flow-diagram or such.

release-manager/files/README.md Show resolved Hide resolved
release-manager/files/README.md Show resolved Hide resolved
release-manager/files/README.md Outdated Show resolved Hide resolved
@BraisVQ BraisVQ merged commit 4527f3a into master Jan 18, 2024
19 checks passed
@BraisVQ BraisVQ deleted the feature/update-rm-readme branch February 19, 2024 12:45
BraisVQ added a commit that referenced this pull request Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants