docs: update workflow and how we use two branchs for ODH and downstre…

…am (opendatahub-io#1582) * docs: update workflow and how we use two branchs for ODH and downstream - add new doc for how workflow, label on PR, sync process - update branch away from incubatin in github action and reference Signed-off-by: Wen Zhou <[email protected]> * Update docs/sync_code.md Co-authored-by: Gerard Ryan <[email protected]> * revert: branch related test config Signed-off-by: Wen Zhou <[email protected]> * fix: typo Signed-off-by: Wen Zhou <[email protected]> --------- Signed-off-by: Wen Zhou <[email protected]> Co-authored-by: Gerard Ryan <[email protected]>
ugiordan · Jan 30, 2025 · da75d42 · da75d42
1 parent f4c932b
commit da75d42
Show file tree

Hide file tree

Showing 2 changed files with 42 additions and 12 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -12,13 +12,14 @@ Issues are tracked using [Jira](https://issues.redhat.com/secure/RapidBoard.jspa
    - **For Feature Requests:**  Set the issue type to be `Initative`
    - **For Bugs:** Set the issue type to `Bug`
    - **For all other code changes:** Use the issue type `Story`
+   - Add "Platform" in "Components" field
 
 ## Pull Requests
 
 ### Workflow
 
 1. **Fork the Repository:** Create your own fork of the repository to work on your changes.
-2. **Create a Branch:** Create your own branch to include changes for the feature or a bug fix off of `incubation` branch.
+2. **Create a Branch:** Create your own branch to include changes for the feature or a bug fix off of `main` branch.
 3. **Work on Your Changes:** Commit often, and ensure your code adheres to these [Code Style Guidelines](#code-style-guidelines) and passes all the [quality gates](#quality-gates) for the operator.
 4. **Testing:** Make sure your code passes all the tests, including any new tests you've added. And that your changes do not decrease the test coverage as shown on report. Every new feature should come with unit tests that cover that new part of the code.
 
@@ -34,10 +35,10 @@ Issues are tracked using [Jira](https://issues.redhat.com/secure/RapidBoard.jspa
 
 To ensure the contributed code adheres to the project goals, we have set up some automated quality gates:
 
-1. [linters](https://github.com/opendatahub-io/opendatahub-operator/blob/incubation/.github/workflows/linter.yaml): Ensure the check for linters is successful. If it fails, run `make lint` to resolve errors
-2. [api-docs](https://github.com/opendatahub-io/opendatahub-operator/blob/incubation/.github/workflows/check-file-updates.yaml): Ensure the api-docs are updated when making changes to operator apis. If it fails, run `make generate manifests api-docs` to resolve errors
-3. [unit-tests](https://github.com/opendatahub-io/opendatahub-operator/blob/incubation/.github/workflows/unit-tests.yaml): Ensure unit tests pass. Run `make unit-tests` 
-4. [e2e-tests](https://prow.ci.openshift.org/job-history/gs/test-platform-results/pr-logs/directory/pull-ci-opendatahub-io-opendatahub-operator-incubation-opendatahub-operator-e2e): Ensure CI job for [e2e tests](https://github.com/opendatahub-io/opendatahub-operator/tree/incubation/tests/e2e) pass. Refer run e2e locally to debug. CI test logs can also be found under `Artifacts` directory under Job details.
+1. [linters](https://github.com/opendatahub-io/opendatahub-operator/blob/main/.github/workflows/linter.yaml): Ensure the check for linters is successful. If it fails, run `make lint` to resolve errors
+2. [api-docs](https://github.com/opendatahub-io/opendatahub-operator/blob/main/.github/workflows/check-file-updates.yaml): Ensure the api-docs are updated when making changes to operator apis. If it fails, run `make generate manifests api-docs` to resolve errors
+3. [unit-tests](https://github.com/opendatahub-io/opendatahub-operator/blob/main/.github/workflows/unit-tests.yaml): Ensure unit tests pass. Run `make unit-tests`
+4. [e2e-tests](https://prow.ci.openshift.org/job-history/gs/test-platform-results/pr-logs/directory/pull-ci-opendatahub-io-opendatahub-operator-main-opendatahub-operator-e2e): Ensure CI job for [e2e tests](https://github.com/opendatahub-io/opendatahub-operator/tree/main/tests/e2e) pass. Refer run e2e locally to debug. CI test logs can also be found under `Artifacts` directory under Job details.
 
 ### Code Style Guidelines
 
@@ -47,7 +48,7 @@ To ensure the contributed code adheres to the project goals, we have set up some
 4. Ensure your code passes `make lint` (we have a .golangci.yml file configured in the repo).
 5. Ensure you write clear and concise comments, especially for exported functions.
 6. Always check and handle errors appropriately. Avoid ignoring errors by using _.
-7. Make sure to run `go mod tidy before` submitting a PR to ensure the `go.mod` and `go.sum` files are up-to-date.
+7. Make sure to run `go mod tidy` before submitting a PR to ensure the `go.mod` and `go.sum` files are up-to-date.
 
 ### Commit Messages
 
@@ -66,12 +67,7 @@ We follow the conventional commits format for writing commit messages. A good co
 ## Sync Changes in Downstream
 
 After a PR is merged into the upstream `opendatahub-io/opendatahub-operator` repository, the changes need to be synced with the downstream repository:
-
-1. **Cherry-Pick:** Use `git cherry-pick` to apply the changes to the downstream repo ([rhods-operator](https://github.com/red-hat-data-services/rhods-operator)).
-2. **Version Labels:** Ensure the downstream PR is labeled with the target release version (e.g., `rhoai-2.14`).
-3. **Operator Bundle or Dockerfile Updates:** If changes affect the operator bundle or Dockerfile, sync the changes in the `rhods-cpaas-midstream` repo in addition to downstream PR.
-
-Follow the same [PR Guide](#pull-requests) for creating and reviewing downstream PRs.
+detail see (./docs/sync_code.md#basic-workflow-for-operator)
 
 ## Communication
 

diff --git a/docs/sync_code.md b/docs/sync_code.md
@@ -0,0 +1,34 @@
+# Basic workflow for Operator
+
+1. Create a branch:
+Start by creating a branch from "main" branch.
+
+2. Ensure local tests pass:
+Run unit and e2e tests, and ensure they pass before submitting a pull request (PR) targeting "main" branch.
+If the PR is associated with any Jira ticket, include the ticket link in the "Description" section of the PR.
+
+
+3. Review and merge PR:
+Once the PR has passed github checks and is reviewed and approved, the PR author should merge it into "main" branch.
+
+4. Create a downstream sync PR:
+The PR author should then create another PR targeting "rhoai" branch. Preferably, the PR title should include the prefix [sync], and the "rhoai" label should be added to help reviewers quickly acknowledge it.
+If the PR is associated with any Jira ticket, include the ticket link in the "Description" section of the PR.
+
+5. Merge sync PR:
+After the sync PR has passed github checks and is reviewed and approved, the PR author should merge it into "rhoai" branch.
+
+6. Automated sync:
+Automation will sync changes to the RHDS rhods-operator on a daily basis.
+
+# PR labels
+
+These labels are optional but help streamline the review and release processes:
+
+- odh-X.Y: Indicates that the change is planned for inclusion in the ODH release X.Y
+- rhoai-X.Y: Specifies the target for a future downstream release. The PR may not need to merge immediately or might have lower review priority.
+- rhoai: For [sync] PRs that bring changes from "main" branch to downstream.
+- testing: Used for PRs focused solely on unit or e2e tests without any code changes (including code refactoring or improvements).
+- documentation: changes on README.md, CONTRIBUTING.MD or files in `docs` folder 
+- component/X: For integration work related to a specific component X. Component owners can be requested as reviewers if needed.
+- multi-arch: Indicates changes specific to non-x64 architectures.