← Back to team overview

ubuntu-appstore-developers team mailing list archive

Re: Determining CI low-hanging fruits

 

Hello everybody,

to clarify the tests I suggested a bit, I could imagine the following
work items.

On 19.09.2013 15:05, Daniel Holbach wrote:
> = Suggested tests =
> 1.  Dev uses ubuntu-sdk (qtcreator) to create a .click package
>  - A (Step 1): Keep a list of app projects, check all of them
>      out and run lp:qtcreator-plugin-ubuntu scripts on them
>      (whenever qtcreator-plugin-ubuntu changes), generate
>      .click packages. Validate packages.

 - Determine initial list of projects (Core apps? Touch+Core apps?).
 - Write a broken app(?).
 - Make click review tools available on Launchpad.
 - Determine which CI tools let us most easily branch code, run
   QtC tools, then run validation scripts on generated .click tools.
 - Write code to run the tests automatically. (Not very explicit
   work item, right?)
 - Hook up with CI infrastructure.

Which other qtcreator-plugin-ubuntu scripts do we want to test? For
which would we need QtC running? For which an attached device?


> 2.  The .click is uploaded to the review website
> 3.  Our reviewers check the .click and approve it in the website
>  - B (Step 2+3): Keep a list of .click packages. Run validation
>      scripts on them server side (whenever scripts or click
>      change).

 - Test-run of current review scripts across current list of approved
   and rejected apps.
 - Reach out to app authors of approved apps to let them know of
   breakage, if we find any.
 - Set up a list of known-good and known-failing tests.
 - Write code to run the tests automatically.
 - Hook up with CI infrastructure.


> 5.  unity-scope-click gets the list of .clicks from the click
>     index webservice
>  - C (Step 5): ? Maybe some validation of the results from the
>      store?

Can anyone comment on the kinds of breakage we saw here?


> 10. Download finishes, ubuntu-download-manager calls “pkcon
>     install-local”
> 11. pkcon uses packagekit dbus api to talk to click pk plugin
> 12. click does the unpacking, calls hooks to create apparmor
>     profile and .desktop files
>  - D (Step 10-12): Keep a list of .click packages (whenever
>      relevant bits - which? - change), check if everything gets
>      installed in the right place and generated files make sense.

Which paths does other code rely on? Do we have validation code for any
of the generated files?


> 13. unity-scope-click creates list of installed packages from
>     .desktop files
>  - E (Step 13) ? Check for duplicates? Check for missing icons,
>      etc?

I'm no expert here. Does autopilot help us here? Can we mock navigation
and verify data in the scope easily?


> 14. user taps on installed app, app is started with the right
>     apparmor profile
>  - F (Step 14) ?

Ideas?


Any comments would be very welcome. Be it different choice of tests,
work items, priorities or comments about feasibility or ease of
implementation.

Thanks a bunch in advance!

Have a great day,
 Daniel

-- 
Get involved in Ubuntu development! developer.ubuntu.com/packaging
Follow @ubuntudev on identi.ca/twitter.com/facebook.com/G+


Follow ups

References