Diff for "Soyuz/QA"

Not logged in - Log In / Register

Differences between revisions 3 and 11 (spanning 8 versions)
Revision 3 as of 2011-01-05 14:15:59
Size: 2097
Comment: fix title
Revision 11 as of 2020-11-17 10:06:41
Size: 5215
Editor: twom
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
(See also the Effective QA section in BuildFarm) (See also the Effective QA section in BuildFarm - you must visit this if you made changes in the publisher because builders need to access the archives)
Line 22: Line 22:
staging runs its own instance of the buildd-manager and has its own builder, clementine. This means that any builds that are queued will get processed and built. Builds can be created in 2 main ways:

 * copying packages without binaries
 * uploading new source

Since qastaging does not run the uploader the latter is not possible, so you need to copy some package in the UI to make a build job. Visit the Copy Packages link on any PPA page.

Because the publisher also doesn't run on staging, the built binaries will remain in limbo for ever (the green cog icon).
staging does not currently run any builders (references to 'clementine' are outdated). Similar QA to qastaging can be performed here. If building QA is absolutely required here, it could theoretically have scalingstack access, but that is not set up.
Line 33: Line 26:
Dogfood is the original QA platform for Soyuz and some developers have shell access which is necessary to run the scripts and work with production-like data. Since this machine is not open for general access to developers, anyone wishing to QA changes to the following things will need to contact a member of the original Soyuz team to do their QA for them. Dogfood is the original QA platform for Soyuz and some developers have shell access which is necessary to run the scripts and work with production-like data. Since this machine is not open for general access to developers, anyone wishing to QA changes to the following things will need to contact a member of Canonical launchpad team.
Line 42: Line 35:
 * Poppy (and poppy-sftp)  * Any package build types that require a buildd.
Line 44: Line 37:
Dogfood has limited resources and is starting to get close to disk space limitations when restoring the production database. We generally only restore once per 6 months after production initialises a new Ubuntu release, as it's more effective to restore the database (~40 hours) than to initialise new series on dogfood. Dogfood is very, very slow. Dogfood has limited resources and is starting to get close to disk space limitations when restoring the production database. The database is restored very irregularly, and on no fixed schedule. Dogfood is very, very slow.

== Getting more QA facilities on [qa]staging ==

It should be easy to run the txpkgupload daemon, and the upload processor and process-accepted script cron jobs on staging. It should also be possible to ask a LOSA to run one of the archive-admin scripts manually, when required, with no issues.

The publisher is a very different matter, because of the nature of the staging database getting restored every week, it will get out of sync with the published repositories. This can cause OOPSes in the scripts, some of which will be false alarms but will still look odd to the uninitiated. At best it will be transient, at worst it will block the publisher and hence QA. There are also some problems with librarian files getting expired in production that are not expired in staging which will also make the publisher fall over.

The PPA signing private keys are also not available outside of production - we remove the references in the dogfood DB to avoid the publisher problems in that area but if they need to be tested then it presents some manual work.

So, some more thought needs to be put into how best to handle publishing on staging.

== Package Builds ==

On a new release of [[https://launchpad.net/launchpad-buildd|launchpad-buildd]] or soyuz code involved in building any of the various types, it is important to test that the builds succeed.

=== Translation Templates ===

You probably want:
 * [[https://dev.launchpad.net/Translations/GenerateTemplatesOnTestServers|TranslationTemplates on Test Servers|]]
 * [[https://dev.launchpad.net/Translations/GenerateTemplatesOnLocalBuildFarm| TranslationTemplates on Local Build Farm]]

=== Source Package Recipe Build ===

There is a full [[https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted|Procedure]] for creating a recipe and uploading it to launchpad.

A shorter way is to use an existing project on dogfood and create a new recipe (or build an existing one). [[https://code.dogfood.paddev.net/~canonical-launchpad-branches/launchpad-buildd/+git/launchpad-buildd|launchpad-buildd]] is a good candidate.

 1. Create a recipe
 2. Either 'Use an existing PPA' if you have one, or create a new one.
 3. Bionic and Xenial are a good choice for distribution series
 4. Request a build

A Source Package Recipe Build that builds into a PPA will also cause a Binary Package Build to happen, but it is still worth testing that separately.

=== Binary Package Build ===

These are created on the upload of a package for building into a PPA.

 1. [[https://dogfood.paddev.net/~/+activate-ppa|Create a PPA]]. This can be skipped if you've already done this.
 2. Follow the [[Soyuz/ReUploadPackage]] instructions. `sl` is a good candidate package.

A Source Package Recipe Build will also cause these builds to happen.

=== OCI Image Build ===

See [[Soyuz/QA/OCI]]

=== Snap Build ===

Snap builds require a git branch to build from. It is slightly awkward to arrange for dogfood to do this, as it has no turnip or similar. Fortunately, snaps support building from external repositories, which can be either production launchpad (launchpad.net), github, or similar service.

 1. Create a snap on dogfood via `lp-shell`: `lp.snaps.new(name='test-from-api', owner=lp.me, git_repository_url='url-to-repository', git_path='branch-to-build')
 2. Find the snap via the [[https://dogfood.paddev.net/~/+snaps|Web UI]]
 3. Request a build of the snap

QA on Soyuz

(See also the Effective QA section in BuildFarm - you must visit this if you made changes in the publisher because builders need to access the archives)

There are three places you can do QA for Soyuz:

  • dogfood
  • [qa]staging
  • staging

QA on qastaging

qastaging only runs the UI side of Soyuz services, so you can only test code that runs in the webapp:

  • PPA copying operations
  • API operations
  • template/browser code changes
  • (add more here)

QA on staging

staging does not currently run any builders (references to 'clementine' are outdated). Similar QA to qastaging can be performed here. If building QA is absolutely required here, it could theoretically have scalingstack access, but that is not set up.

QA on dogfood

Dogfood is the original QA platform for Soyuz and some developers have shell access which is necessary to run the scripts and work with production-like data. Since this machine is not open for general access to developers, anyone wishing to QA changes to the following things will need to contact a member of Canonical launchpad team.

  • The Publisher (PPA or Ubuntu), which includes
    • publish-distro.py
    • process-accepted.py
    • cron.germinate (this one is owned by the Ubuntu team but we test it for them)
    • process-death-row.py
  • The upload processor (process-upload.py)
  • Ubuntu archive management tools (everything in scripts/ftpmaster-tools/)
  • Any package build types that require a buildd.

Dogfood has limited resources and is starting to get close to disk space limitations when restoring the production database. The database is restored very irregularly, and on no fixed schedule. Dogfood is very, very slow.

Getting more QA facilities on [qa]staging

It should be easy to run the txpkgupload daemon, and the upload processor and process-accepted script cron jobs on staging. It should also be possible to ask a LOSA to run one of the archive-admin scripts manually, when required, with no issues.

The publisher is a very different matter, because of the nature of the staging database getting restored every week, it will get out of sync with the published repositories. This can cause OOPSes in the scripts, some of which will be false alarms but will still look odd to the uninitiated. At best it will be transient, at worst it will block the publisher and hence QA. There are also some problems with librarian files getting expired in production that are not expired in staging which will also make the publisher fall over.

The PPA signing private keys are also not available outside of production - we remove the references in the dogfood DB to avoid the publisher problems in that area but if they need to be tested then it presents some manual work.

So, some more thought needs to be put into how best to handle publishing on staging.

Package Builds

On a new release of launchpad-buildd or soyuz code involved in building any of the various types, it is important to test that the builds succeed.

Translation Templates

You probably want:

Source Package Recipe Build

There is a full Procedure for creating a recipe and uploading it to launchpad.

A shorter way is to use an existing project on dogfood and create a new recipe (or build an existing one). launchpad-buildd is a good candidate.

  1. Create a recipe
  2. Either 'Use an existing PPA' if you have one, or create a new one.
  3. Bionic and Xenial are a good choice for distribution series
  4. Request a build

A Source Package Recipe Build that builds into a PPA will also cause a Binary Package Build to happen, but it is still worth testing that separately.

Binary Package Build

These are created on the upload of a package for building into a PPA.

  1. Create a PPA. This can be skipped if you've already done this.

  2. Follow the Soyuz/ReUploadPackage instructions. sl is a good candidate package.

A Source Package Recipe Build will also cause these builds to happen.

OCI Image Build

See Soyuz/QA/OCI

Snap Build

Snap builds require a git branch to build from. It is slightly awkward to arrange for dogfood to do this, as it has no turnip or similar. Fortunately, snaps support building from external repositories, which can be either production launchpad (launchpad.net), github, or similar service.

  1. Create a snap on dogfood via lp-shell: `lp.snaps.new(name='test-from-api', owner=lp.me, git_repository_url='url-to-repository', git_path='branch-to-build')

  2. Find the snap via the Web UI

  3. Request a build of the snap

Soyuz/QA (last edited 2023-03-13 13:54:28 by cjwatson)