@@ -16,94 +16,6 @@ It is automatically run on a daily basis based on the following [openshift/relea
16
16
If the bumper program fails to create a mergeable PR, manual intervention will be necessary.
17
17
This may require copying, modifying and resubmitting the PR.
18
18
19
- ## Assumptions
20
-
21
- The helper scripts assume that the upstream remote repos are configured
22
- as follows:
23
- ```
24
- git remote add api https://github.com/operator-framework/api
25
- git remote add operator-registry https://github.com/operator-framework/operator-registry
26
- git remote add operator-lifecycle-manager https://github.com/operator-framework/operator-lifecycle-manager
27
- ```
28
- The [ sync.sh] ( sync.sh ) script will automatically create these
29
- remote repositories.
30
-
31
- ## Bulk Sync
32
-
33
- ** NOTE** : This should no longer be necessary, given the "bumper" program above.
34
- The "bumper" program can be used instead of the following process.
35
-
36
- To sync all current changes from upstream, simply run the sync script:
37
- ``` sh
38
- scripts/sync.sh
39
- ```
40
-
41
- This script may pause at certain points to ask the user to examine
42
- command failures or possible regressions. Please open another terminal
43
- and review the state of the workspace before continuing the script.
44
-
45
- When the script completes, it will have created a branch whose name is
46
- the current date (formatted: ` sync-YYYY-MM-DD ` ).
47
-
48
- If the ` sync.sh ` script fails, please refer to
49
- [[ 1] ( https://spaces.redhat.com/display/OOLM/Downstream+to+operator-framework-olm )]
50
- for continuation proceedures.
51
-
52
- Before this branch can be used to create a PR, run the following:
53
- ``` sh
54
- make -k verify
55
- ```
56
- If there are any diffs or modified files, these need to be added to
57
- your branch as either a separate commit (e.g. headline: ` Run make verify ` ),
58
- or amended to the last commit of the branch.
59
-
60
- Once ` make -k verify ` is resolved, create a PR from this sync branch.
61
-
62
-
63
- ## Targeted Sync
64
-
65
- To sync a subset of commits from the upstream repositories (i.e. critical
66
- bugfix), create a new working sync branch. Then create a ` sync.cherrypick `
67
- file in the repositry root directory with the repos and commit SHAs.
68
-
69
- The format of the cherrypick file is:
70
- ```
71
- <date-order> <commit-order> <repo> <commit-SHA>
72
- ```
73
-
74
- * The ` <date-order> ` field is usually an ISO date without spaces.
75
- * The ` <commit-order> ` field is a sequential number indicating the order of a commit within a pull request.
76
- * For this _ manual_ purpose, both can just be the same sequential number.
77
-
78
- For example:
79
- ```
80
- 1 1 api 0123456789abcdef0123456789abcdef01234567
81
- 2 2 operator-lifecycle-manager 123456789abcdef0123456789abcdef012345678
82
- 3 3 operator-lifecycle-manager 23456789abcdef0123456789abcdef0123456789
83
- ```
84
- Do _ not_ commit the cherrypick file, it is a temporary working file that
85
- is ignored by ` git ` .
86
-
87
- Then run the following:
88
- ``` sh
89
- scripts/sync_pop_candidate.sh -a sync
90
- ```
91
- The commits in the ` sync.cherrypick ` file will be applied in the specified
92
- order.
93
-
94
- Even if you only have a single commit, this procedure will follow the same
95
- process that ` sync.sh ` does, to ensure no steps are missed.
96
-
97
- Before this branch can be used to create a PR, run the following:
98
- ``` sh
99
- make -k verify
100
- ```
101
- If there are any diffs or modified files, these need to be added to
102
- your branch as either a separate commit (e.g. headline: ` Run make verify ` ),
103
- or amended to the last commit of the branch.
104
-
105
- Once ` make -k verify ` is resolved, create a PR from this working sync branch.
106
-
107
19
# Long-lived Carry Commits
108
20
109
21
It is required at times to write commits that will live in the ` vendor/ ` directory
0 commit comments