NewbieGuide
Size: 4814
Comment:
|
Size: 7475
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 9: | Line 9: |
* wait for new rows in the spreedsheet (the CI-SNCF bot will notify you) and perform the "steps for a landing" described below | * wait for new rows in the spreadsheet (the CI-SNCF bot will notify you) and perform the "steps for a landing" described below |
Line 17: | Line 17: |
* Its all in one google spreedsheet https://wiki.ubuntu.com/citrain that mostly updates itself automatically (its a frontend to jenkins) * First column in the spreedsheet is important! Keep attention to the number of free silos, try to keep 1 slio free for emergency landings * The spreedsheet has multiple page (sheets), the main one is "pending", but there is also "Archive" that contains *all* of the history and pages for each landing slio. |
* Its all in one google spreadsheet https://wiki.ubuntu.com/citrain that mostly updates itself automatically (its a frontend to jenkins) * First column in the spreadsheet is important! Keep attention to the number of free silos, try to keep 1 silo free for emergency landings * You have a preproduction code silo in silo-000. You only have access to it if you check "use preproduction silo" * The spreadsheet has multiple page (sheets), the main one is "pending", but there is also "Archive" that contains *all* of the history and pages for each landing silo. |
Line 21: | Line 22: |
* Additional source packages to land: you need to dput these additional source packages from the archive into the silo PPA | * Additional source packages to land: you need to dput these additional source packages from the archive into the silo PPA. Then, you run a build. If a build was already done, you can just run "watch ppa" to let the bot rescan the ppa content. |
Line 26: | Line 27: |
== Jenkins jobs parameters == By default, CI-Train was designed so that all jobs needs no parameters for the default action. Those parameters are overrides for special cases and should only be used as such. The only "generally used" override is the ACK_PACKAGING when there are packaging changes. |
|
Line 29: | Line 33: |
* check if the package is locked already (via hoover over column F) | * check if the package is locked already (via hoover over column F). CI-train will tell you if it's locked. There is an available override (but who lands first will force the second to rebuild to take latest content or its publication will fail). |
Line 36: | Line 40: |
* check that the speedsheet updates after some time * the details for the landing are in a spreedsheet page N, e.g. "landing-07" * its the job of the lander to click on "BUILD" on this spreedsheet page (which will bring you to a PPA) |
* check that the speadsheet updates after some time * CI-SNCF will ping the lander once the silo is ready for building. * the details for the landing are in a spreadsheet page N, e.g. "landing-07" * its the job of the lander to click on "BUILD" on this spreadsheet page (which will bring you to a PPA) |
Line 40: | Line 45: |
* once that is the case, we go to the landing sheet of the spreedsheet and click on "PUBLISH" | * once that is the case (CI-SNCF or the lander will ping you), we go to the landing sheet of the spreadsheet and click on "PUBLISH" |
Line 43: | Line 48: |
* ??? * lander will click on "merge & clean" |
* the status columns of the spreadsheet (or using inspect <silo_name> or inspect <line_number>) on CI-SNCF will update automatically when the package migrate (like, it's a NEW package, it's in UNAPPROVED, -proposed, -release pocket). Be ready to help the landers with your expertise if something is stuck in -proposed for too long for instance, or ensure that packages in NEW are treated… * lander will click on "merge & clean" once the package is in the release pocket (CI-SNCF will ping the landers). There is an override available. |
Line 47: | Line 52: |
* when a landing is build the ci-train bot will say so in the #ubuntu-ci-train-choo-choo channel * check what landing number it is (e.g. landing-017) and go to the spreedsheet page (sheet) of that number |
* when a landing is build the ci-train bot will say so in the #ubuntu-ci-choo-choo channel * check what landing number it is (e.g. landing-017) and go to the spreadsheet page (sheet) of that number * '''WARNING''' always check that "TESTING DONE" field in the land page (e.g. landing-001) is set to YES |
Line 50: | Line 56: |
* '''WANRING''' publish means to publish into the REAL archive - do not publish '''NEW''' packages without consulting | |
Line 58: | Line 65: |
* no spreedsheet | * no spreadsheet, but still manual details filing (so equivalent) |
Line 62: | Line 69: |
* full spec and vision: https://docs.google.com/a/canonical.com/presentation/d/1LQK5Xll3D-G_zSFgFFDZiCmIZ8P33b_C7crefECsquA/edit#slide=id.p | |
Line 67: | Line 75: |
* TrainCon-Zero: when no new image is generated for 7 buisiness days this "emergency" state is reached and only critical fixes can go in * CI Train Sherrif is the guy/gal currently doing landings |
* TrainCon-Zero: when no new image is generated for 7 business days this "emergency" state is reached and only critical fixes can go in * CI Train Sheriff is the guy/gal currently doing landings |
Line 72: | Line 80: |
* Jenkins that is controlled via the spreedsheet: https://ci-train.ubuntu.com/ * Code for the spreedsheet: lp:cupstream2distro |
* Jenkins that is controlled via the spreadsheet: https://ci-train.ubuntu.com/ * Code for the spreadsheet: https://script.google.com/a/macros/canonical.com/d/Mm1HGi6clLW7PBeK0cuo8t0wI2BjkVmPv/edit?uiv=2&tz=Europe/Paris&docTitle=CI+Train+(new+spreadsheet)&csid=tUGCqn02F-FBjb_J63mhwZw.17677642142287030301.6922350451819992316&mid=ACjPJvGMAAigLtZGWBm-WJBBUACdAZbVK5PYfqjoatma36YhKhVOsAmpLs8awUz5WgYkvogMzkFL2IwNdqPjtnBd4hYgkWUyl5u-5LKlW4KLOC4M3CM&hl=en_US. This code handles the syncing from the jenkins backend, control integrity, updates, archiving, assignements, conflicts and latest promoted/proposed images numbers fetching. * Backend code (running on jenkins): lp:cupstream2distro. The CI-train code is under the citrain/ directory. It uses the cupstream2distro library (initially designed for the Daily Release process). |
Line 79: | Line 89: |
* The Daily release FAQ is valid under citrain: https://wiki.ubuntu.com/DailyRelease/FAQ (apart from "When do changes need to land in a coherent piece?" and "I want one of my commit not being part of debian/changelog") |
Newbie guide
What you need to know if you are new to the citrain landing team:
What do do
- read this document
- join #ubuntu-ci-eng
- join #ubuntu-ci-choo-choo and highlight on "trainguards" (the bot "CI-SNCF" has a bunch of commands (like where unity8))
- wait for new rows in the spreadsheet (the CI-SNCF bot will notify you) and perform the "steps for a landing" described below
- wait for stuff to be ready for publishing (the bot will tell you about it) and perform the "steps for publishing" below
- the expectation is to do up to 50% of your work time on landings
What is it
The citrain is a tool to coordinate landing of new features. This includes building/testing and publishing.
Its all in one google spreadsheet https://wiki.ubuntu.com/citrain that mostly updates itself automatically (its a frontend to jenkins)
- First column in the spreadsheet is important! Keep attention to the number of free silos, try to keep 1 silo free for emergency landings
- You have a preproduction code silo in silo-000. You only have access to it if you check "use preproduction silo"
- The spreadsheet has multiple page (sheets), the main one is "pending", but there is also "Archive" that contains *all* of the history and pages for each landing silo.
- Merge propoosal to land (row F) is important, order of the branches is important. Branches are not limited to a single project
- Additional source packages to land: you need to dput these additional source packages from the archive into the silo PPA. Then, you run a build. If a build was already done, you can just run "watch ppa" to let the bot rescan the ppa content.
- QA sign off needed: only in effect if we are in train-con-zero - and then *only* stuff with QA-sign-off: no can enter the image
- Ready? : really important, once its ready, assign to a silo via "landing team tools/assign silo" menu item (more see below)
Jenkins jobs parameters
- By default, CI-Train was designed so that all jobs needs no parameters for the default action. Those parameters are overrides for special cases and should only be used as such. The only "generally used" override is the ACK_PACKAGING when there are packaging changes.
Steps for a landing
- landing for a request:
- check if it has a testplan
- check if the package is locked already (via hoover over column F). CI-train will tell you if it's locked. There is an available override (but who lands first will force the second to rebuild to take latest content or its publication will fail).
- check that its ready
- go to the "Landing team tools" menubar and click on "assign silo"
- this generates a request-id that is valid for 5min
- opens a dialog that you need to check
- the jenkins tab opens, click on "proceed"
- opens a jenkins job page
- check that the speadsheet updates after some time
- CI-SNCF will ping the lander once the silo is ready for building.
- the details for the landing are in a spreadsheet page N, e.g. "landing-07"
- its the job of the lander to click on "BUILD" on this spreadsheet page (which will bring you to a PPA)
- once the thing is ready and the lander has executed the test plan he/she sets the status column to testing-done
- once that is the case (CI-SNCF or the lander will ping you), we go to the landing sheet of the spreadsheet and click on "PUBLISH"
- this brings you to jenkins
- if there are changes in debian/* it generates a diff and that needs approval first via the "ACK_PACKAGING" box in the build jenkins subpage and press "build"
the status columns of the spreadsheet (or using inspect <silo_name> or inspect <line_number>) on CI-SNCF will update automatically when the package migrate (like, it's a NEW package, it's in UNAPPROVED, -proposed, -release pocket). Be ready to help the landers with your expertise if something is stuck in -proposed for too long for instance, or ensure that packages in NEW are treated…
lander will click on "merge & clean" once the package is in the release pocket (CI-SNCF will ping the landers). There is an override available.
Steps for publishing
- when a landing is build the ci-train bot will say so in the #ubuntu-ci-choo-choo channel
- check what landing number it is (e.g. landing-017) and go to the spreadsheet page (sheet) of that number
WARNING always check that "TESTING DONE" field in the land page (e.g. landing-001) is set to YES
- click on "publish" there, that links to a jenkins page
WANRING publish means to publish into the REAL archive - do not publish NEW packages without consulting
- click on "build"
- if there are packaging changes the circle on the left will turn yellow and you need to review the build artifcat with the packaging diff (e.g. packaging_changes_nuntium_0.1+14.10.20140702.2-0ubuntu1.diff), then click on "Build with Parameters" on the left and select ACK_PACKAGING_CHANGES
- the status should be "blue" (successful), you can close the jenkins tab now
- now the lander needs to cleanup the silo, the bot will notify him/her
What about CI-Airline
- will replace all of CI-Train
- no spreadsheet, but still manual details filing (so equivalent)
- no jenkins
see http://blueprints.launchpad.net/ubuntu/+spec/core-1311-ci-airline
- designed by didrocks, worked on by citeam
full spec and vision: https://docs.google.com/a/canonical.com/presentation/d/1LQK5Xll3D-G_zSFgFFDZiCmIZ8P33b_C7crefECsquA/edit#slide=id.p
- will be ready ~July 2014
Terms
- Silo are PPAs that are used to prepare a landing
- Landers are trusted people of the upstream project who can drive landing and do the final testing
TrainCon-Zero: when no new image is generated for 7 business days this "emergency" state is reached and only critical fixes can go in
- CI Train Sheriff is the guy/gal currently doing landings
Links
Main landing spreadsheet: https://wiki.ubuntu.com/citrain (refreshes every 5min)
Jenkins that is controlled via the spreadsheet: https://ci-train.ubuntu.com/
This code handles the syncing from the jenkins backend, control integrity, updates, archiving, assignements, conflicts and latest promoted/proposed images numbers fetching.
- Backend code (running on jenkins): lp:cupstream2distro. The CI-train code is under the citrain/ directory. It uses the cupstream2distro library (initially designed for the Daily Release process).
Testing results: http://ci.ubuntu.com/smokeng/utopic/touch/
Low-level JSON with the silo status: http://people.canonical.com/~platform/citrain/
new coolness: http://people.canonical.com/~rbpark/citrain/
Who is who: https://wiki.ubuntu.com/citrain/LandingTeam
The Daily release FAQ is valid under citrain: https://wiki.ubuntu.com/DailyRelease/FAQ (apart from "When do changes need to land in a coherent piece?" and "I want one of my commit not being part of debian/changelog")
citrain/NewbieGuide (last edited 2015-09-02 04:12:32 by 1)