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

doc: How to create new release branch CI files #1247

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

mateusoliveira43
Copy link
Contributor

@mateusoliveira43 mateusoliveira43 commented Nov 30, 2023

Why the changes were made

The goal of this PR is to document the steps needed to create a new release branches, so no steps are missed next time we do it. In the future, this should be automated.

Fixes #1227

How to test the changes made

Read the documentation and make sure it is clear. Check referenced PRs in linked issue to see if no steps were missed.

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 30, 2023
Copy link

openshift-ci bot commented Nov 30, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 10, 2024
@mateusoliveira43

This comment was marked as resolved.

@openshift-ci openshift-ci bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 10, 2024
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 18, 2024
@mateusoliveira43 mateusoliveira43 marked this pull request as ready for review July 18, 2024 14:38
@mateusoliveira43

This comment was marked as outdated.

@openshift-ci openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. and removed do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. labels Jul 18, 2024
@mateusoliveira43 mateusoliveira43 marked this pull request as draft July 18, 2024 17:25
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 18, 2024
@mateusoliveira43 mateusoliveira43 marked this pull request as ready for review July 29, 2024 19:28
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 29, 2024
@mateusoliveira43

This comment was marked as outdated.

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 29, 2024
@openshift-ci openshift-ci bot requested a review from sseago July 29, 2024 19:28
kaovilai
kaovilai previously approved these changes Jul 29, 2024
@@ -0,0 +1,10 @@
# This Dockerfile WILL used by PROW CI to run E2E tests of the repo

Choose a reason for hiding this comment

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

Duplicate file ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

uhum

after merge I will open a CI PR (in openshift/release) to CI to use this new dockerfile; and then, another PR to remove build/ folder from here, to fix #1259

sseago
sseago previously approved these changes Jul 29, 2024
@mateusoliveira43
Copy link
Contributor Author

/override ci/prow/4.15-e2e-test-aws
restore succeeds, but deployment/deploymentConfig never goes to ready state flake

Copy link

openshift-ci bot commented Jul 30, 2024

@mateusoliveira43: Overrode contexts on behalf of mateusoliveira43: ci/prow/4.15-e2e-test-aws

In response to this:

/override ci/prow/4.15-e2e-test-aws
restore succeeds, but deployment/deploymentConfig never goes to ready state flake

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@mateusoliveira43
Copy link
Contributor Author

/override ci/prow/4.16-e2e-test-aws
restore succeeds, but deployment/deploymentConfig never goes to ready state flake

Copy link

openshift-ci bot commented Jul 30, 2024

@mateusoliveira43: Overrode contexts on behalf of mateusoliveira43: ci/prow/4.16-e2e-test-aws

In response to this:

/override ci/prow/4.16-e2e-test-aws
restore succeeds, but deployment/deploymentConfig never goes to ready state flake

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.


https://github.com/openshift/oadp-operator/issues/1227
To create new OADP release branches (they must follow the pattern `oadp-major.minor`, [example](https://github.com/openshift/oadp-operator/tree/oadp-1.4)):
- First, create CI files for each new repository branch.
Copy link
Contributor

Choose a reason for hiding this comment

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

What CI Files? Is there a link or information what theCI files are ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, in this same file, there are links to each OADP repo CI files

example https://github.com/openshift/oadp-operator/blob/master/docs/developer/PROW_CI.md?plain=1#L5-L8

https://github.com/openshift/oadp-operator/issues/1227
To create new OADP release branches (they must follow the pattern `oadp-major.minor`, [example](https://github.com/openshift/oadp-operator/tree/oadp-1.4)):
- First, create CI files for each new repository branch.
- Create the release branches in each one of related repositories of OADP, and OADP operator repository itself.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have a clear list of those repositories? Maybe a link so no repo is forgotten?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, in this same file, at the top

Copy link
Contributor

Choose a reason for hiding this comment

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

Since it's *.md make it a link?

- First, create CI files for each new repository branch.
- Create the release branches in each one of related repositories of OADP, and OADP operator repository itself.
- The new release branches must be updated:
- Downstream repositories release branches may not need updates (except OADP operator, which always need updates).
Copy link
Contributor

Choose a reason for hiding this comment

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

  • Downstream OADP operator always requires updates.
  • Other downstream repositories and their release branches generally do not need updates.
    - Write when they may require updates

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I do not know if there is a clear when

Copy link
Contributor

Choose a reason for hiding this comment

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

Any suggestions? This can't be made based on judgement, rather some agreement when it's needed so someone who makes new branch knows at least what to look for. I think it's something to be discussed on scrum.

- Downstream repositories release branches may not need updates (except OADP operator, which always need updates).
- Upstream repositories release branches need to be rebased.

> **Note**: Try to always create release branches from default branches (usually called master).
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we have a little help here:

The default branch of a given repository can be checked using the following command

$ curl -s https://api.github.com/repos/openshift/oadp-operator | jq -r .default_branch
master

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this can be checked through UI, do not think we need this

Copy link
Contributor

Choose a reason for hiding this comment

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

It can be checked in many way of course. But with new branch you usually use shell or UI? either one works if it's the one to continue. I believe we don't want the user to switch between UI and shell, rather have set of instructions within one.


> **Note**: Try to always create release branches from default branches (usually called master).

> **Note**: Documentation should live only in default branches. For example, for OADP operator, `docs/` and `blogs/` folders can be deleted in release branches.
Copy link
Contributor

Choose a reason for hiding this comment

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

can or should be deleted? Leaving option to leave it would be softer then explicitly stating that we only want the default branch to be updated with docs. Does the default branch carries over old design documentation, or proper instructions for a given branch? What if the instructions are changing in master branch? Do we keep the correct ones for a given branch?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we currently do not delete, I want to start doing this

we have old docs in master yes, like this https://github.com/openshift/oadp-operator/blob/master/docs/upgrade_1-1_to_1-2.md

Copy link
Contributor

Choose a reason for hiding this comment

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

So I would make this document clear that we do delete and then continue with implementation (deletion). Note, this won't affect rebases and cherry-picks?

...
```

Create `ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4.yaml`. To make it easier, copy the contents of `ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master.yaml` (if release branch was created from master branch), changing the following.
Copy link
Contributor

Choose a reason for hiding this comment

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

What about that part of the file? I thought we want to make sure it's inline with the ocp version that the ci is running on?

build_root:
  image_stream_tag:
    name: builder
    namespace: konveyor
    tag: ubi9-v1.22.2

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this is responsibility of this issue #1455

Copy link
Contributor

Choose a reason for hiding this comment

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

On the above there is commend As it is not valid anymore after..., so either resurrect there or fix here.


> **Note**: to get diff between files, you can run `diff -ruN ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master.yaml ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4.yaml`.

Create `ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4__4.VERSION.yaml` files. To make it easier, copy the contents of `ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master__4.VERSION.yaml` files (if release branch was created from master branch), changing the following.
Copy link
Contributor

Choose a reason for hiding this comment

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

There is no such file in the release folder:

$ ls ci-operator/config/openshift/oadp-operator/*VERSION*
ls: cannot access 'ci-operator/config/openshift/oadp-operator/*VERSION*': No such file or directory

Copy link
Contributor

Choose a reason for hiding this comment

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

Here is list of files

$ ls ci-operator/config/openshift/oadp-operator/*
ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master__4.14.yaml    ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.0.yaml        ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4__4.14.yaml
ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master__4.15.yaml    ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.3__4.12.yaml  ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4__4.15.yaml
ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master__4.16.yaml    ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.3__4.13.yaml  ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4__4.16.yaml
ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-master.yaml          ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.3__4.14.yaml  ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4.yaml
ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.0__4.12.yaml  ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.3__4.15.yaml  ci-operator/config/openshift/oadp-operator/OWNERS
ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.0__4.14.yaml  ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.3.yaml

Copy link
Contributor Author

Choose a reason for hiding this comment

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

VERSION is the minor version of OCP, the regex should be ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-<branch-name>__4.*.yaml

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah ok so it's not clear then, it needs to be:

ci-operator/config/openshift/oadp-operator/openshift-oadp-operator-oadp-1.4__4.${MINOR_VERSION}.yaml

docs/developer/PROW_CI.md Show resolved Hide resolved
docs/developer/PROW_CI.md Show resolved Hide resolved
@mateusoliveira43 mateusoliveira43 dismissed stale reviews from sseago and kaovilai via b691b60 July 30, 2024 12:31
Copy link

openshift-ci bot commented Jul 30, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mateusoliveira43

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

2 similar comments
Copy link

openshift-ci bot commented Jul 30, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mateusoliveira43

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link

openshift-ci bot commented Jul 30, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mateusoliveira43

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mateusoliveira43
Copy link
Contributor Author

/retest

Copy link

openshift-ci bot commented Jul 30, 2024

@mateusoliveira43: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@weshayutin
Copy link
Contributor

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. CI do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document new branching steps
7 participants