-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathREADME.automation
183 lines (151 loc) · 8.74 KB
/
README.automation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
Ca-certificates automation, updated Jul 14, 2022
For the theory of ca-certificates update, see README.md.
Automation implements everything in README.md as scripts (using some of the
scripts in that README).
There are two main driving scripts to do this:
./build_combo.sh
Which takes a list of options as well as various releases you want to release:
./build_combo.sh [-r] [-t nss_type] [-n nss_release] [-f] releases"
-d use the development tip rather than the latest release
-n nss_release fetch a specific nss release (default latest)
-t nss_type type of nss release to fetch (RTM,BETA1,BETA2)
-f cert_datadir fetch certdata.txt, nssckbi.h, and nss.h from a
directory instead of upstream
releases:
fxx for fedora builds
rawhide for fedora current developement builds
rhel-x.x for rhel5,rhel6,rhel7 builds
rhel-x.x.x for rhel-8,rhel-9 builds
./build_combo.sh operation
- downloads the requested certdata.txt and headers from a particular
NSS build into ./cacerts
- processes it for each release and puts the resulting certdata.txt in
./modified
- pulls the appropriate git trees under the ./packages and updates the
files in that release
- creates a file meta/rhel_list and meta/fedora_list which includes the
current releases and builds
Example of typical use:
# pull and build the latest on fedora, rhel5, rhel6 rhel7 and rhel8
./build_combo.sh f43 f44 rawhide rhel-5.10 rhel-6.10 rhel-7.9 rhel-8.3.0 rhel-8.4.0 rhel-8.5.0 rhel-8.6.0
./process.py
which takes the following options
./process.py [-r rhel.list] [-o owner.email] [-m manager.email] [-q qa.email] [-v ckbi.version] [-f firefox.version] [-y year] [-e errataurlbase]')
-r rhel.list location of the rhel.list (./meta/rhel.list)
-o owner.email errata owner's email (read from config.cfg)
-m manager.email errrata owner's manager's email( read from config.cfg)
-q qa.email errata qa's email (read from config.cfg)
-v ckbi.version ckbi version number read from ./meta/ckbiversion.txt)
-f firefox.version the version of firefox associated with this release
-y year year of the release (current year)
-e errataurlbase url of the errrata system (https://errata.devel.redhat.com)
-b bugurlbase url of the bugzilla system (https://bugzilla.redhat.com)
./process.py operation
process.py tries to do as much as possible in completing the tasks needed
for release.
-it looks up bugs, and if they don't exists creates them (exception:
z-stream bugs are created by the system once the y-stream bug has moved
to MODIFIED ./process.py knows this and only tries to look up the
z-stream bugs).
- once bugs are created, the changes in the tree are committed with
the bug number.
- if the bugs have the appropriate acks, the changes are pushed to git.
- if the changes are pushed, and builds haven't been made, the system
tries to start builds
- if you have bugs in modified, erratas are creates (if the errata
already exists, it is found).
- if builds are complete, they are attached to the errata.
- bugs are attached to the errata.
- once erratas have complete builds and bugs attached, that release is
considered complete.
before running ./process.py, you need to create a config.cfg file with the
following:
manager:{errrata owner's manager's email}
ownerr:{errata owner's email}
qe:{errata qa's email}
bugzilla_login:{bugzilla login}
bugzilla_apikey:{bugzilla apikey}
A sample config.cfg.sample is included. config.cfg is in .gitignore to prevent
pushing your private apikey to the public repository. You can get an apikey
from bugzilla by going to https://bugzilla.redhat.com/userprefs.cgi?tab=apikey
and following the instructions. Be sure to copy the API key from the bugzilla
UI as soon as it's created. Once you leave the page, it will no longer be
available.
If you don't include a bugzilla apikey, ./process.py may not be able
find z-stream bugs, as well as create or modify bugs.
If you don't supply manager, owner, or qe, ./process.py will not be able to
create erratas.
On your first invocation of ./process.py, you need to specify a firefox
release. ./process.py will remember that release on later calls.
You will also make sure you have kerberos tokens or most operation will fail.
Example:
./process -f 91
The intension is ./process.py is run periodically, it stops when blocked.
The tool outputs the final state, which indicates what needs to be done to
move forward:
state meaning action to move forward
waiting bug clone waiting for a The y-stream bug needs to be in the
z-stream bug modified state with the appropriate
to be cloned flags set.
from the y-stream.
need bug no bug for * check bugzilla login info
y-stream and * verify bugzilla config
create failed * hand create bug with the subject
'Annual {year} ca-certificates update'
* If bug exists, you can hand add the
bug number to ./meta/rhel_list or
./meta/fedora_list
bug needs ack bugs don't have get the required acks
the requires acks
for checking
patch need push patch is checked git push probably failed, could be:
in to git, but * authentication failure
push failed * additional bug flags that are
missing.
* running 'rhpkg push' by hand in
the appropriate ./packages
subdirectory will usually give the
reason
builds not started for some reason * rerun ./process.py. if problem
builds are pushed, persists, try running 'rhpkg build'
but the builds by hand in the appropriate
weren't started ./packages subdirectory.
builds failed builds failed * check brew for the issue and
correct
builds in progress brew is currently * wait for builds to complete
running builds
builds in gating gating is running * check brew for the gating status
on the build, or if gating failed, diagnose gating
gating has failed error and fix
needs errata no errata found * make sure config.cfg is correct
and create failed * make sure you have valid kerberos
tickets
* hand create errata
need builds attached builds complete, * make sure config.cfg is correct
but not attached to * make sure you have valid kerberos
errata tickets
* hand add builds to errata
needs bugs attached bugs in modified * make sure config.cfg is correct
but not attached * make sure you have valid kerberos
to errata tickets
* hand add bugs to errata
complete Builds are complete
and attached to
errata, bugs are
attached to errata
The following states are error states in ./process.py and indicate a
programming error or difficency in ./process.py:
builds complete, state error - should not happen (problem with ./process.py)
builds in an unknown state - should not happen (problem with ./process.py)
You can complete any steps you want by hand and ./process.py will automatically
recognize that step (checkin, pushing, building, errata and bug creation, etc).
./meta/rhel.list includes the current state, you can modify ./meta/rhel.list
to:
1) force a refresh (set bug and errata numbers to 0 will force a new lookup)
1) force a particular bug or errata number
2) remove packages
3) force a complete refresh (bug, errata=0 nvr='' state=stale)
each run everything is refreshed except bug and errata numbers, and state=complete
./meta/fedora.list includes the current state for fedora. Fedora does not
require acks on the bugs, do anything with errata. Fedora updates currently
need to be manually invoked.