The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)


Test process

From Mer Wiki
(Difference between revisions)
Jump to: navigation, search
(New page: = Process = We center Mer contribution around our Gerrit instance and git, http://monster.tspre.org:8080 . Every single package is in git and the Core (+ ports) is described in xml files ...)
 
m (update url)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
= Process =
 
= Process =
  
We center Mer contribution around our Gerrit instance and git, http://monster.tspre.org:8080 . Every single package is in git and the Core (+ ports) is described in xml files inside a git repository.
+
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@monster.tspre.org gerrit review PATCHSET -m "Message" --code-review SCORE
+
Code review: ssh -p 29418 username@review.merproject.org gerrit review PATCHSET -m "Message" --code-review SCORE
  
== When a change to a package is done ===
+
== When a change to a package is proposed ==
  
=== Step X: Checking if it builds on it's own ===
+
=== Step V: Validate packaging ===
 +
Validate proposed changes + packaging as being OK
  
 +
=== 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
+
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. Change ref can be found with 'ssh -p 29418 username@monster.tspre.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs.
+
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 31: Line 33:
 
  </repository>
 
  </repository>
 
</code>
 
</code>
6. Wait for build to finish of package for each architecture. For '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 ===
+
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 41: Line 43:
 
1. Create unique OBS repository, REPO
 
1. Create unique OBS repository, REPO
  
2. Create package (basename of project/packagename) in 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. Change ref can be found with 'ssh -p 29418 username@monster.tspre.org gerrit query status:merged --patch-sets --format JSON' (status:merged can be any kind of query) and it will give you patchsets + refs.
+
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 sources to OBS package in REPO
+
4. Upload updated sources to OBS package in REPO, ignoring _meta and _attribute
  
 
5. Set up localdep:
 
5. Set up localdep:
Line 57: Line 59:
 
</code>
 
</code>
  
6. Wait for it to finish building. If there is '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"
+
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. Delete project REPO
+
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.

Personal tools