Tuesday, September 17, 2013

Running *hidden* Firefox for Android 4.2 x86 tests

As of last night, we're running *hidden* the first two sets of Android 4.2 x86 test jobs on every Gecko 27 tree on tbpl:
https://tbpl.mozilla.org/?jobname=Android 4.2 x86&rev=2520866d5874&showall=1
More sets will be added as we green the test suites on Cedar.
Image from http://en.wikipedia.org/wiki/File:Android-x86.png
Side topic, if you have an Android x86 or Armv6 device and want to test Firefox for it please give it a shot in https://play.google.com/store/apps/details?id=org.mozilla.firefox_beta&hl=en

Back to the topic, there are various aspects of the Android x86 testing which are different from the rest of our mobile automated testing, here's a brief list:

  • We don't run them on a device like a Tegra board or a Panda board
    • We run them on Linux 64-bit in-house machines (we can't use AWS)
    • No foopies involved
  • We run them under the Android emulator for the x86 architecture
  • We test on Android 4.2 rather than on Android 2.2 or 4.0
  • We run them in parallel: four emulator instances at most
  • An Android x86 job on tbpl is called a "set"
    • All Android x86 jobs will be grouped under "Sets" rather than per suite category grouping (e.g. reftest or mochitest)
    • A set can run test suites from any category (mix mochitests with reftests)
Here's how it looks on tbpl:







From a developer's perspective here's what you need to know:
  • The jobs are currently not running visibly on tbpl
  • Android x86 is on its way to become a tier-1 platform
  • You can borrow a releng machine to run the tests on them
    • You will be able to run it on your machine if this bug gets fixed
  • We're greening more suites on Cedar and we will add them to other tbpl development trees
  • We could potentially be adding another 7 to 11 sets in the next few weeks
  • The suites on each set are currently in-flux as we move suites from orange sets to green sets
  • Android x86 testing will ride the Gecko 27 trains


    In a following blog post I will go into the technical details on how these tests are run by mozharness.

    All of this work happened under bug 895186.

    If you want to contribute on how to make them easily runnable outside of a releng machine please visit this bug.


    After several months of development, big thanks (sorted alphabetically) to aki, Callek, dminor, gbrown, rail, RyanVM and ted.

    We still have some work to go but it is good to capture this small step towards victory.

    Upcoming:





    Creative Commons License
    This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

    Tuesday, July 30, 2013

    Enabling talos mozharness for FF25 development trees

    Today we have enabled talos mozharness (jyeo's blog post) on all FF25 development trees on tbpl.mozilla.org.
    This is a project that jyeo has completed during his internship at Mozilla's Release Engineering.
    Credit to jyeo
    What are the implications of this?

    • It reduces chaos.
      • You can run talos the same way as our infrastructure does to minimize differences
    • It makes contributions easier.
      • You can contribute to talos mozharness without having to install and setup Buildbot
    • It removes deployments.
      • We can deploy changes without having to wait on the buildbot masters to be reconfigured
        • This makes specially the A-team very happy
      • The A-team does not have to create talos.zip files
        • The A-team does not have to wait on us to upload the talos.zip
        • Developers don't need to request or create a talos.zip since we use the talos repo directly
    • It makes easier developing and testing new talos changes.
      • We can make configuration changes in an easier manner and it is locked to a given changest rather than affecting a whole branch
        • It can ride the trains
        • It only requires changes to talos.json
        • This makes testing new configuration changes on try easier
      • Mozharness also gives us a lot of flexibility
        • Including a finer control on the usage of Python packages
    • We even have mach support!
      • This makes it trivial for developers to run talos in their beloved objdirs (blog post)


    Cons:




    Creative Commons License
    This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

    Friday, July 12, 2013

    Google 2-step verification and how to set up an Android device, a desktop computer and a FirefoxOS phone

    Once in a while I push myself to learn how to use security tools to prevent allowing people to steal my data. I wish security chased me and guided me to set things up without my desire to be secure, however, that is a different story.

    A while ago, I added 2-step authentication with my Google account and my friend catlee showed me how I could have the Google Authenticator Android app on my phone.

    NOTE: To understand 2-step verification visit this site www.google.com/2step

    It took me a while to get used of keeping my phone close by to be able to authenticate. Believe it or not, I can testify that there are people out there that as soon as they get home they put their phones on a desk and walk away from it for hours.

    I recently got a Keon Geeksphone running FirefoxOS and I was carrying my Android phone to be able to authenticate. After few days of asking around somebody pointed out the GAuth Authenticator WEB APP (this means that you can also run it in your browser) on Mozilla's Marketplace. At first, I was sceptic because I thought I had to give my Google credentials to a third-party company and that made me very uncomfortable. This was a misunderstanding from my part as I don't have to give my credentials at all.

    NOTE: Please excuse me if there is a better workflow or I'm misunderstanding the concept.

    Given this background, I will jump straight into the steps that I needed to follow to do this:
    VERY IMPORTANT NOTE: Set all your devices all at once with the same key. Every time you create a new key and "verify and save" it, you will be nullifying any previous keys that had been generated. All of your Google Authentication apps should be activated with the same code.
    For GAuth you will need to use the key rather than the QR code
    • Besides "Mobile Application" you will see "Android", "iPhone" and "Blackberry"
      • Click on one of them and stick with it
      • "Android" and "iPhone" will show you a QR code, however, you can use a key if you click on "Can't scan the barcode?"
      • GAuth on your FirefoxOS phone
      • "Blackberry" will only show you a key
    • Install Google Authenticator for your Android device
      • Open the app and click on the settings icon at the top right
      • "Set up account"
      • "Scan a barcode"
      • Point your camera at your desktop's browser where you have clicked on the "Android" link mentioned above
    • Install GAuth Authenticator on your FirefoxOS phone or on your desktop through Firefox (Chrome or IE won't work)
      • Open the app
      • Click on the "+" sign
      • Give the account a name
      • Enter the key that Google gives you
    NOTE: On your desktop machine, Firefox will install the Web app as a regular application (e.g. /Applications for Mac)

    NOTE2: If I install the app through Firefox Beta instead of Nightly, Mac will prevent the app from running the web app due to security concerns. I believe all you have to do is go to the Applications folder and do a right click and click "Open". This should add an exception according to this article.
    Happy 2-step authentication!


    Creative Commons License
    This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.