The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Test process
(Undo revision 271 by 153.96.46.161 (Talk)) |
m (update url) |
||
| (3 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
= Process = | = Process = | ||
| − | We center Mer contribution around our Gerrit instance and git, http:// | + | We center Mer contribution around our Gerrit instance and git, http://review.merproject.org/ . Every single package is in git and the Core (+ ports) is described in xml files inside a git repository. It is possible to monitor gerrit events with 'gerrit stream-events' |
== Terms == | == Terms == | ||
| Line 7: | Line 7: | ||
QA build server: OBS that does builds to verify if sources work okay | QA build server: OBS that does builds to verify if sources work okay | ||
| − | Code review: ssh -p 29418 username@ | + | Code review: ssh -p 29418 username@review.merproject.org gerrit review PATCHSET -m "Message" --code-review SCORE |
== When a change to a package is proposed == | == When a change to a package is proposed == | ||
=== Step V: Validate packaging === | === Step V: Validate packaging === | ||
| − | + | Validate proposed changes + packaging as being OK | |
| − | + | ||
=== Step X: Checking if it builds on it's own === | === Step X: Checking if it builds on it's own === | ||
| − | |||
1. Create unique OBS repository, REPO | 1. Create unique OBS repository, REPO | ||
2. Create package (basename of project/packagename) in REPO, by linkpacing fakeobs:Core:ARCH packagename | 2. Create package (basename of project/packagename) in REPO, by linkpacing fakeobs:Core:ARCH packagename | ||
| − | 3. Locally, check out git (GERRIT/project/packagename) and merge proposed change from branch. | + | 3. Locally, check out git (GERRIT/project/packagename) and merge the proposed change from branch. The change ref can be found with 'ssh -p 29418 username@review.merproject.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs. |
4. Upload sources to OBS package in REPO | 4. Upload sources to OBS package in REPO | ||
| Line 35: | Line 33: | ||
</repository> | </repository> | ||
</code> | </code> | ||
| − | |||
| − | + | 6. Wait for the end of the package build for each architecture. For a 'succeeded' build, code review with +1 "Looks good to me, but someone else must approve", for failed, code review with -1 "I would prefer that you didn't submit this" along with URL to build log. For 'excluded', report which architecture in comment with 0, no score. | |
| + | === Step X+1: Integration testing === | ||
This will check the package does not break other packages. | This will check the package does not break other packages. | ||
| Line 47: | Line 45: | ||
2. Create package (basename of project/packagename) in REPO by linkpacing fakeobs:Core:ARCH packagename | 2. Create package (basename of project/packagename) in REPO by linkpacing fakeobs:Core:ARCH packagename | ||
| − | 3. Locally, check out git (GERRIT/project/packagename) and merge proposed change from branch. | + | 3. Locally, check out git (GERRIT/project/packagename) and merge proposed change from branch. The change ref can be found with 'ssh -p 29418 username@review.merproject.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs. |
4. Upload updated sources to OBS package in REPO, ignoring _meta and _attribute | 4. Upload updated sources to OBS package in REPO, ignoring _meta and _attribute | ||
| Line 61: | Line 59: | ||
</code> | </code> | ||
| − | 6. Wait for it to finish building. If there | + | 6. Wait for it to finish building. If there are 'failed' packages, review to gerrit -1 "I would prefer that you didn't submit this", along with which packages it broke and URLs to their build logs, else +1 "Looks good to me, but someone else must approve" |
| − | 7. If successful, pass on (method unknown so far) repository+changeset id to Core vendors for them to test as part of images, else delete repository | + | 7. If successful, pass on (method unknown so far) repository+changeset id to Core vendors for them to test as part of images, else delete repository. |
Latest revision as of 18:39, 23 December 2011
Contents |
[edit] Process
We center Mer contribution around our Gerrit instance and git, http://review.merproject.org/ . Every single package is in git and the Core (+ ports) is described in xml files inside a git repository. It is possible to monitor gerrit events with 'gerrit stream-events'
[edit] Terms
QA build server: OBS that does builds to verify if sources work okay
Code review: ssh -p 29418 username@review.merproject.org gerrit review PATCHSET -m "Message" --code-review SCORE
[edit] When a change to a package is proposed
[edit] Step V: Validate packaging
Validate proposed changes + packaging as being OK
[edit] Step X: Checking if it builds on it's own
1. Create unique OBS repository, REPO
2. Create package (basename of project/packagename) in REPO, by linkpacing fakeobs:Core:ARCH packagename
3. Locally, check out git (GERRIT/project/packagename) and merge the proposed change from branch. The change ref can be found with 'ssh -p 29418 username@review.merproject.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs.
4. Upload sources to OBS package in REPO
5. Point to repositories in REPO:
for each ARCH, ARCHSCHEDULER, add in
<repository name="Core_ARCH"> <path repository="Core_ARCH" project="fakeobs:Core:ARCH" /> <arch>ARCHSCHEDULER</arch> </repository>
6. Wait for the end of the package build for each architecture. For a 'succeeded' build, code review with +1 "Looks good to me, but someone else must approve", for failed, code review with -1 "I would prefer that you didn't submit this" along with URL to build log. For 'excluded', report which architecture in comment with 0, no score.
[edit] Step X+1: Integration testing
This will check the package does not break other packages.
For each ARCH, ARCHSCHEDULER:
1. Create unique OBS repository, REPO
2. Create package (basename of project/packagename) in REPO by linkpacing fakeobs:Core:ARCH packagename
3. Locally, check out git (GERRIT/project/packagename) and merge proposed change from branch. The change ref can be found with 'ssh -p 29418 username@review.merproject.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs.
4. Upload updated sources to OBS package in REPO, ignoring _meta and _attribute
5. Set up localdep:
<link project="fakeobs:Core:ARCH" /> <repository name="Core_ARCH" linkedbuild="localdep"> <path repository="Core_ARCH" project="fakeobs:CORE:ARCH" /> <arch>ARCHSCHEDULER</arch> </repository>
6. Wait for it to finish building. If there are 'failed' packages, review to gerrit -1 "I would prefer that you didn't submit this", along with which packages it broke and URLs to their build logs, else +1 "Looks good to me, but someone else must approve"
7. If successful, pass on (method unknown so far) repository+changeset id to Core vendors for them to test as part of images, else delete repository.
