Hello!
One of the bigger components of https://www.mediawiki.org/wiki/User:Yuvipanda/Android_app_releases is getting CI builds that are available after every commit for the Android app. Am trying to collect all the tasks that'll need to be done for that to work properly, so we can get them all done :D My goal is to have CI builds for the app available and usable by end of July
1. Setup jenins to be able to build Android apps 1a. Add a puppet role that installs and maintains an Android SDK setup 1b. Add this to the Jenkins roles, will probably still run on labs rather than production 1c. Add a small script that'll rename the package name to org.wikipedia.alpha and set the version as well (extend our make-beta script) 1d. Add jenkins job to build the apk, and add a Zuul trigger to trigger the job on every commit-merge. This should also run the make-alpha script before building. 1e. Make sure that the apks built are tagged with appropriate commit hashes / dates. 2. Build small wrapper app that checks jenkins for new builds and notifies the user of any builds newer than the one they have. Should have easy download + 1 tap to install. 3. Build small 'status' web page where people can check current build / download it / download the wrapper app (for first time use)
I'll work with Dan to get these prioritized and scheduled. Anything I missed?
Yay to CI builds!
Yuvi,
Re: 1c: Why do we need to change the package name to org.wikipedia.alpha? Didn't you mention that we're getting rid of alpha?
Bernd
On Wed, Jul 16, 2014 at 4:59 AM, Bernd Sitzmann bsitzmann@wikimedia.org wrote:
Yuvi,
Re: 1c: Why do we need to change the package name to org.wikipedia.alpha? Didn't you mention that we're getting rid of alpha?
Bernd
Right, so we should change it to org.wikipedia.ci or something. This is so people could have both the stable version and the CI version on their phones without having to fiddle with uninstall/reinstall every time.
On Tue, Jul 15, 2014 at 4:30 PM, Yuvi Panda yuvipanda@gmail.com wrote:
Right, so we should change it to org.wikipedia.ci or something. This is so people could have both the stable version and the CI version on their phones without having to fiddle with uninstall/reinstall every time.
I really don't want to have to uninstall/reinstall for each update.
Make sure we can run both.
--tomasz
With this you will be able to have three variants of the app installed at the same time: - ci - beta - stable
And no uninstall required. :)
Bernd
On Wed, Jul 16, 2014 at 12:41 PM, Tomasz Finc tfinc@wikimedia.org wrote:
On Tue, Jul 15, 2014 at 4:30 PM, Yuvi Panda yuvipanda@gmail.com wrote:
Right, so we should change it to org.wikipedia.ci or something. This is so people could have both the stable version and the CI version on their phones without having to fiddle with uninstall/reinstall every time.
I really don't want to have to uninstall/reinstall for each update.
Make sure we can run both.
--tomasz
These cards are now accounted for in sprint 36. They still need estimating, and we'll see how it fits in with our priorities during the meeting.
Dan
On 15 July 2014 14:15, Yuvi Panda yuvipanda@gmail.com wrote:
Hello!
One of the bigger components of https://www.mediawiki.org/wiki/User:Yuvipanda/Android_app_releases is getting CI builds that are available after every commit for the Android app. Am trying to collect all the tasks that'll need to be done for that to work properly, so we can get them all done :D My goal is to have CI builds for the app available and usable by end of July
- Setup jenins to be able to build Android apps
1a. Add a puppet role that installs and maintains an Android SDK setup 1b. Add this to the Jenkins roles, will probably still run on labs rather than production 1c. Add a small script that'll rename the package name to org.wikipedia.alpha and set the version as well (extend our make-beta script) 1d. Add jenkins job to build the apk, and add a Zuul trigger to trigger the job on every commit-merge. This should also run the make-alpha script before building. 1e. Make sure that the apks built are tagged with appropriate commit hashes / dates. 2. Build small wrapper app that checks jenkins for new builds and notifies the user of any builds newer than the one they have. Should have easy download + 1 tap to install. 3. Build small 'status' web page where people can check current build / download it / download the wrapper app (for first time use)
I'll work with Dan to get these prioritized and scheduled. Anything I missed?
Yay to CI builds!
-- Yuvi Panda T http://yuvi.in/blog
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l