feat(adr): Add ADR-0009 (Project Workflow)#52
feat(adr): Add ADR-0009 (Project Workflow)#52ruivieira wants to merge 5 commits intotrustyai-explainability:mainfrom
Conversation
ruivieira
added
ADR
ruivieira
requested review from
RobGeada,
adolfo-ab,
christinaexyou,
ckhordiasma,
dahlem,
danielezonca,
dmaniloff,
evaline-ju,
m-misiura,
nehachopra27 and
sheltoncyril
|
cc @andrewballantyne @dchourasia @zdtsw Your feedback would be greatly appreciated too, if you have the chance. Thanks! |
adr/ADR-0009-project-workflow.md
Outdated
| The project components will follow these release cadences: | ||
| - **Upstream**: Releases every 3 weeks | ||
| - **Midstream (ODH)**: Releases every 3 weeks, coinciding with upstream releases | ||
| - **Downstream**: Monthly releases |
There was a problem hiding this comment.
Changed the downstream cadence to be flexible.
| MI->>MS: 👤 Later promotion when validated | ||
| ``` | ||
|
|
||
| #### Critical Security Fix Path |
There was a problem hiding this comment.
- is this only for Trivy result or downstream Synk too? they might show different sevirity.
- do we follow the same process for downstream "blocker" fix?
There was a problem hiding this comment.
@zdtsw in this proposal, only Trivy is used for upstream (although Snyk could also be used). I mainly saw Trivy as complementing downstream's Snyk, rather than replacing it.
I would need to investigate if Snyk (Open Source tier) allows for integration with workflows (i.e. blocking PR merges if Critical/High CVEs are detected).
IIUC the blocker question, in this proposal critical/blocker fixes for downstream will always be applied upstream, and then fast-tracked to midstream:stable and also cherry picked to the downstream: if needed.
| - Automated smoke tests when syncing with upstream | ||
| - Ensures basic functionality is preserved | ||
|
|
||
| 3. **Midstream:incubation**: |
| - Creates a new branch named `odh/[version]` | ||
| - Tags the branch with `v[version]-odh` | ||
| - Triggers image builds for the release |
There was a problem hiding this comment.
here will be some extra steps (set up tekton pipeline etc) if use konflux
There was a problem hiding this comment.
Made a comment on Konflux setup (although Konflux pipeline details are out of scope for this proposal)
|
|
||
| This schedule allows upstream features to be developed, tested in ODH, and then propagated to downstream after a period of incubation. | ||
|
|
||
| ### Branch Flow |
There was a problem hiding this comment.
i am thinking:
ODH release branch is out of ODH incubation
ODH stable branch is out of ODH incubation as well ( for simplicity, lets say ODH stable == downstream main)
due to different release cycles (3 weeks VS monthly-ish) , wont there be a chance, a commit/feature on ODH incubation has not been sync to ODH release (out as part of ODH release) but get onto ODH stable (in downstream release)?
There was a problem hiding this comment.
@zdtsw This is a good point and a great catch.
I've updated the proposal so that the commit existing on incubation is a requirement for being in stable (with exceptional scenarios, such as critical security fixes).
I also propose a GHA to validate commit ancestry and fail the test on the stable branch if the commit is on stable but not incubation, in case you see any value in having that feedback.
| ### Repository Structure | ||
| - **Upstream**: Single persistent branch: `main` - Used for all development and experimentation | ||
| - **Midstream**: Three persistent branches: | ||
| - `main` - Complete mirror of **upstream:main** | ||
| - `incubation` - Branch for ODH feature testing, validation, and releases (no development) | ||
| - `stable` - Curated set of validated features for downstream consumption | ||
| - **Downstream**: Single persistent branch: `main` - Syncs from **midstream:stable** | ||
| - Temporary feature branches: created via PRs and deleted after merge | ||
| - Release branches: created from **midstream:incubation** for ODH releases (_e.g._, **odh/2.20**, **odh/2.21**) |
There was a problem hiding this comment.
Curious about the way you approach branches.
- Upstream is fine -- resolve as needed
- Midstream auto sync in
mainmakes sense to me incubationseems odd if your code comes from upstream -- why not just build off ofmain?stableis auto-synced for downstream, makes sense
What features/code are you writing in midstream? Where do PRs or feature branches go? Do they merge into main as well?
How do you support ODH/RHOAI specific stuff? Is that avoided and everything goes upstream generically? Do you not need any configuration files or special manifests for downstream to configure generic features?
There was a problem hiding this comment.
@andrewballantyne good points. This proposal's goal is (summarised) to make sure that:
All development happens upstream only; the branches serve different "curation" goals:
- upstream:main → Where all development & experimentation should be made
- midstream:incubation → Curated for ODH (testing & validation only, potentially build-time configurations)
- midstream:stable → Curated for downstream (validated features only, potentially build-time configurations)
Upstream will contain experimental features not ready (necessarily) for ODH production. With midstream:incubation we can:
- Select which features to test in ODH
- Validate component integration
- Exclude features from releases (either by not being mature, or not part of a roadmap)
The proposal aims at no midstream (feature) development. midstream:incubation should only have:
- Cherry-picking validated features
- ODH-specific configuration overlays (or other configurations)
- No code changes (other that configurations)
We also plan to have feature gates (I'll add this to the proposal)
All features will exist upstream but can be disabled/enabled via runtime or build-time configuration in midstream/downstream.
To your question: IMO, building from main would bring the entire upstream kitchen sink to ODH, we were thinking of an additional layer between upstream:main and midstream:stable(==downstream:main) so that we can control and configure features for ODH releases and focus integration testing (using midstream:incubation ODH-specific configuration) and, from incubation, be able to promote to downstream.
Hope that makes sense.
3 participants
No description provided.