-
Notifications
You must be signed in to change notification settings - Fork 43
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tbugfinder
reviewed
Dec 11, 2023
- 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. | ||
|
There was a problem hiding this comment.
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.
metmajer
approved these changes
Jan 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #969 and #974