Subscribe: Armen Zambrano's battlefield
http://www.blogger.com/feeds/18323498/posts/default/-/planet
Added By: Feedage Forager Feedage Grade A rated
Language: Afrikaans
Tags:
bug cgi  bug  bugzilla mozilla  https bugzilla  https  mozilla org  mozilla  org show  org  project  show bug  show  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Armen Zambrano's battlefield

Armen Zambrano's battlefield



This blog mainly contains posts about Mozilla release engineering projects that I am working on and some personal insights.



Updated: 2018-04-21T05:43:18.714-04:00

 



Docker image to generate allthethings.json

2017-04-18T11:14:17.302-04:00

I've created a lot of hackery in the past (mozci) based on Release Engineering's allthethings.json file as well as improving the code to generate it reliably. This file contains metadata about the Buildbot setup and the relationship between builders (a build trigger these tests).

Now, I have never spent time ensuring that the setup to generate the file is reproducible. As I've moved over time through laptops I've needed to modify the script to generate the file to fit my new machine's set up.

Today I'm happy to announce that I've published a Docker image at Docker hub to help you generate this file anytime you want.

You can find the documentation and code in here.

Please give it a try and let me know if you find any issues!
docker pull armenzg/releng_buildbot_docker
docker run --name allthethings --rm -i -t releng_buildbot_docker bash
# This will generate an allthethings.json file; it will take few minutes
/braindump/community/generate_allthethings_json.sh
# On another tab (once the script is done)
docker cp allthethings:/root/.mozilla/releng/repos/buildbot-configs/allthethings.json .


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



Screencast: How to green up Firefox test jobs on new infrastructure

2017-04-04T09:24:10.360-04:00

In this blog post I go over the basics of investigating if a new platform on the continous integration system is ready to run Firefox test jobs.

In this case we look at Windows 7 and Windows 10 jobs on TaskCluster.
Some issues are on the actually machines (black screenshots; audio set up) and others are tests that need developer investigation.

You need about 30 minutes to watch these.

allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/zvFgRZ7NqnI" width="560"> allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/R68YbUw8tp8" width="560">

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



Usability improvements for Firefox automation initiative - Status update #8

2016-10-28T09:33:36.606-04:00

NEW:* Debugging on remote workers is not a main priority for this quarter since it got completed* We've added investigating hyper chunkingOn this update we will look at the progress made in the last two weeks.This quarter’s main focus is on improving end to end times on Try (Thunder Try project).For all bugs and priorities you can check out:https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvementsThunder Try - Improve end to end times on try---------------------------------------------Project #1 - Artifact builds on automation##########################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882Accomplished recently:All --artifact build jobs now provide crash-reporter symbols. This means test jobs scheduled against linux64 debug work with --artifact.Upcoming:Patch in review - debug artifact builds on try. (Right now --artifact always results in an opt artifact build.)Project #2 - S3 Cloud Compiler Cache####################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641Accomplished recently:Green builds on all platforms on Try, planning to compare build times vs. existing Python sccache nowProject #3 - Metrics####################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856Accomplished recently:Stabilized dashboard http://people.mozilla.org/~klahnakoski/MoBuildbotTimings/End-to-End.htmlTaskCluster ingestion is Mozharness steps is now working, but not shown on charts yet.Upcoming:Still has the “small population” problem, where outliers make the 90th percentile look big.Add a TaskCluster view of End-to-End timesStart knocking off bugs in the dashboardProject #4 - Build automation improvements##########################################Nothing new for this editionProject #5 - Hyper chunking###########################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262834Nothing new for this editionProject #6 - Run Web platform tests from the source checkout############################################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286900Feature blocked on misconfigured EBS volumes in AWS (bug 1305174)This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



Usability improvements for Firefox automation initiative - Status update #7

2016-10-12T10:48:27.300-04:00

On this update we will look at the progress made in the last two weeks.A reminder that this quarter’s main focus is on:Debugging tests on interactive workers (only Linux on TaskCluster)Improve end to end times on Try (Thunder Try project)For all bugs and priorities you can check out the project management page for it:https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvementsStatus update:Debugging tests on interactive workers---------------------------------------------------Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262260Accomplished recently:No new progressUpcoming:Android xpcshellBlog/newsgroup postThunder Try - Improve end to end times on try---------------------------------------------Project #1 - Artifact builds on automation##########################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882Accomplished recently:The following platforms are now supported: linux, linux64, macosx64, win32, win64An option was added to download symbols for our compiled artifacts during the artifact buildUpcoming:Debug artifact builds on try. (Right now --artifact always results in an opt artifact build.) Android artifact builds on try, thanks to nalexander.Project #2 - S3 Cloud Compiler Cache####################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641Some of the issues found last quarter for this project was around NSS which also was in need of replacing. This project was put on hold until the NSS work was completed. We’re going to resume this for Q4.Project #3 - Metrics####################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856Accomplished recently:Brittle running example here:  http://people.mozilla.org/~klahnakoski/temp/End-to-End.htmlProblem with low populations; 90th percentile is effectively everything, and a couple of outliers impacts the End-to-End time shown. Upcoming:Figure out what to do with these small populations:Ignore them - too small to be statistically significantAggregate them - All the rarely run suites can be pushed into a “Other” categoryShow some other statistic:  Maybe median is better?Show median of past day, and 90% for the week:  That can show the longer trend, and short term situation, for better overall feel.Project #4 - Build automation improvements##########################################Accomplished recently:Bug 1306167 - Updated build machines to use SSD. Linux PGO builds now take half the timehttps://bugzilla.mozilla.org/show_bug.cgi?id=1306167#c11Project #5 - Run Web platform tests from the source checkout############################################################Nothing to add on this edition.This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



[NEW] Added build status updates - Usability improvements for Firefox automation initiative - Status update #6

2016-09-28T13:34:07.807-04:00

[NEW] Starting on this newsletter we will start giving you build automation improvements since they help with the end to end time of your pushesOn this update we will look at the progress made in the last two weeks.A reminder that this quarter’s main focus is on:Debugging tests on interactive workers (only Linux on TaskCluster)Improve end to end times on Try (Thunder Try project)For all bugs and priorities you can check out the project management page for it:https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvementsStatus update:Debugging tests on interactive workers---------------------------------------------------Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262260Accomplished recently:Fixed regression that broke the interactive wizardSupport for Android reftests landedUpcoming:Support for Android xpcshellVideo demonstrationThunder Try - Improve end to end times on try---------------------------------------------Project #1 - Artifact builds on automation##########################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882Accomplished recently:Windows and Mac artifact builds are soon to land|mach try| now supports --artifact optionCompiled-code tests jobs error-out early when run with --artifact on tryUpcoming:Windows and Mac artifact builds available on TryFix triggering of test jobs on Buildbot with artifact buildProject #2 - S3 Cloud Compiler Cache####################################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641Nothing new in this edition.Project #3 - Metrics####################Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856Accomplished recently:Drill-down charts:Which lead to a detailed view: With optional wait times included (missing 10% outliers, so looks almost the same):Upcoming:Iron out interactivity bugsShow outliers Post these (static) pages to my people pageFix ActiveData production to handle these queries (I am currently using a development version of ActiveData, but that version has some nasty anomalies)Project #4 - Build automation improvements##########################################Upcoming:We identified an interaction with EBS in AWS that is likely making several parts of automation slower than they should be (https://bugzilla.mozilla.org/show_bug.cgi?id=1305174)Project #5 - Run Web platform tests from the source checkout############################################################Accomplished recently:WPT is now running from the source checkout in automationUpcoming:There are still parts in automation relying on a test zip. Next steps is to minimize those so you can get a loner, pull any revision from any repo, and test WPT changes in an environment that is exactly what the automation tests run in.Other#####Bug 1300812 - Make Mozharness downloads and unpacks actions handle better intermittent S3/EC2 issuesThis adds retry logic to reduce intermittent orangesThis work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



Increasing test coverage

2016-09-13T17:27:08.043-04:00

Last quarter I spent some time increasing mozci's test coverage. Here are some notes I took to help me remember in the future how to do it.

Here's some of what I did:
  • Read Python's page about increasing test coverage
    • I wanted to learn what core Python recommends
    • Tthey recommend is using coverage.py
  • Quick start with coverage.py
    • "coverage run --source=mozci -m py.test test" to gather data
    • "coverage html" to generate an html report
    • "/path/to/firefox firefox htmlcov/index.html" to see the report
  • NOTE: We have coverage reports from automation in coveralls.io
    • If you find code that needs to be ignored, read this.
      • Use "# pragma: no cover" in specific lines
      • You can also create rules of exclusion
    • Once you get closer to 100% you might want to consider to increase branch coverage instead of line coverage
    • Once you pick a module to increase coverage
      • Keep making changes until you run "coverage run" and "coverage html".
      • Reload the html page to see the new results
      After some work on this, I realized that my preferred place to improve tests is focusing on the simplest unit tests. I say this since integration tests do require proper work and thinking how to properly test them rather than *just* increasing coverage for the sake of it.


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



      Usability improvements for Firefox automation initiative - Status update #2

      2016-08-02T15:48:43.682-04:00

      On this update, we will look at the progress made since our initial update.A reminder that this quarter’s main focus is on:Debugging tests on interactive workers (only Linux on TaskCluster)Improve end to end times on Try (Thunder Try project)For all bugs and priorities you can check out the project management page for it:https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvementsDebugging tests on interactive workersTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262260Accomplished recently:Bug 1285582 - Fixed Xvfb startup issueBug 1288827 - Improved mochitest UX (no longer need --appname, paths normalized)Bug 1289879 - Uses mozharness venv if availableUpcoming:Support for smaller test harnesses (Cpp, Mn, wpt, etc)Improved one-click-loaner UX[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1285582[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1288827[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1289879Thunder Try - Improve end to end times on tryProject #1 - Artifact builds on automationTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882No news for this edition and probably the next one.Project #2 - S3 Cloud Compiler CacheTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641Accomplished recently:Working on testing sccache re-write on TryMore news on following updateProject #3 - MetricsTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856Accomplished recently:Bug 1242017 - Metrics team will configure ingestion point into TelemetryUpcoming:Bug 1258861 - Working on underlying data model at the moment: [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1242017[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1258861OtherBug 1287604 - Experiment with different AWS instance types for TC linux64 buildsSome initial experiments have shown we can shave 20 minutes off an average linux64 build by using more powerful AWS instances, with a reasonable cost tradeoff. We’ll start the work of migrating to these new instances soon.Bug 1272083 - Downloading and unzipping should be performed as data is receivedProject for investigation has been started: https://github.com/armenzg/download_and_unpackBug 1286336 - Improve interaction of automation with version controlBuildbot AMIs now seeded with mozilla-unified repo (Bug 1232442)TaskCluster decision and various lint/test tasks now use `hg robustcheckout` and share caches more optimally (Bug 1247168)Flake8 tasks now complete in as little as 9s (~3m before)Decision tasks now complete in Some TaskCluster tasks now share VCS checkouts on Try (Bug 1289643)Tasks will complete faster on Try due to not having to perform full VCS checkout[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1287604[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1272083[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1247168This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



      Mozci and pulse actions contributions opportunities

      2016-07-21T15:47:18.337-04:00

      We've recently finished a season of feature development adding TaskCluster support to add new jobs to Treeherder on pulse_actions.I'm now looking at what optimizations or features are left to complete. If you would like to contribute feel free to let me know.Here's some highligthed work (based on pulse_action issues and bugs):Use Treeherder as the source for querying jobsThis will help us save money in Heroku since using Buildapi + buildjson files is memory hungry and requires us to use bigger Heroku nodes.Allow controlling pulse_actions production behaviour with environment variables This is important to help us change the behaviour of the Heroku app without having to commit any code. I've used this in the past to modify the logging level when debugging an issue.This is also useful if we want to have different pipelines in Heroku. Create a staging pipelineHaving Heroku pipelines help us to test different versions of the software.This is useful if we want to have a version running from 'master' against the staging version of Treeherder.It would also help contributors to have a version of their pull requests running live.Create test planWe don't have any tests running. We need to determine how to run a minimum set of tests to have some confident in the product.This needs integration tests of Pulse messages.Nightly jobs started with Treeherder do not schedule properlyThe comment is the bug is rather accurate and it shows that there are many small things that need fixing.Manual backfilling does not take advantage of TC/BBB schedulingManual backfilling uses Buildapi to schedule jobs. If we switched to scheduling via TaskCluster/Buildbot-bridge we would get better results since we can guarantee proper scheduling of a build + associated dependent jobs. Buildapi does not give us this guarantee. This is mainly useful when backfilling PGO test and talos jobs.If instead you're interested on contributing to mozci you can have a look at the issues.This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



      Usability improvements for Firefox automation initiative - Status update #1

      2016-07-19T08:44:30.752-04:00

      The developer survey conducted by Engineering Productivity last fall indicated that debugging test failures that are reported by automation is a significant frustration for many developers. In fact, it was the biggest deficit identified by the survey. As a result,the Engineering Productivity Team (aka A-Team) is working on improving the user experience for debugging test failures in our continuous integration and speeding up the turnaround for Try server jobs.This quarter’s main focus is on:Debugging tests on interactive workers (only Linux on TaskCluster)Improve end to end times on Try (Thunder Try project)For all bugs and priorities you can check out the project management page for it:https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvementsIn this email you will find the progress we’ve made recently. In future updates you will see a delta from this email.PS = These status updates will be fortnightlyDebugging tests on interactive workersAccomplished recently:Landed support for running reftest and xpcshell via tests.zipMany UX improvements to the interactive loaner workflowUpcoming:Make sure Xvfb is running so you can actually run the tests!Mochitest support + all other harnessesThunder Try - Improve end to end times on tryProject #1 - Artifact builds on automationTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882Accomplished recently:Landed prerequisites for Windows and OS X artifact builds on try.Identified which tests should be skipped with artifact buildsUpcoming:Provide a try syntax flag to trigger only artifact builds instead of full builds; starting with opt Linux 64.Project #2 - S3 Cloud Compiler CacheTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641Accomplished recently:Sccache’s Rust re-write has reached feature parity with Python’s sccacheNow testing sccache2 on TryUpcoming:We want to roll out a two-tier sccache for Try, which will enable it to benefit from cache objects from integration branchesProject #3 - MetricsTracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856Accomplished recently:Preliminary analytics / research based on job data from Treeherder found at: http://nbviewer.jupyter.org/url/people.mozilla.org/%7Ewlachance/try%20analysis.ipynbWhich jobs finish last?Which jobs have the highest wait times?Which jobs have the longest total wall clock time (i.e. are the largest consumers of resources)Upcoming:Putting Mozharness steps’ data inside Treeherder’s database for aggregate analysisOtherUpcoming:TaskCluster Linux builds are currently built using a mix of m3/r3/c3 2xlarge AWS instances, depending on pricing and availability. We’re going to be looking to assess the effects on build speeds of using more powerful AWS instances types, as one potential way of reducing e2e Try times.https://bugzilla.mozilla.org/show_bug.cgi?id=1287604This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



      Adding new jobs to Treeherder is now transparent

      2016-06-30T18:41:33.634-04:00

      As of today, when you add new jobs to a push on Treeherder (among other actions), a job will get scheduled named 'Sch' for scheduling.

      This gives two main advantages:

      • You can have access to the output of how the request went
      • A a link to file a bug under the right component and CC me

      You can see in this screenshot what the job looks like:
      In this push you can see three 'Sch' jobs. Each one is for a different action taken.
      1. Backfill a job - Link to log
      2. Add new jobs - Link to log
      3. Trigger all talos jobs - Link to log
      You can find the link to filing a bug after you do this:

      1. Click on job (the job's panel will load at the bottom of the page)
      2. Click on "Job details"
      3. You will see "File bug" (see the screenshot below)
      Thanks for reading and feel free to file bugs to make the output more understandable!



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



      Q2 retropective

      2016-06-29T15:29:48.444-04:00

      This quarter has been a tough one for me. It has been a mix of organizing people, projects and implementing prototypes. It’s easy to forget what you have worked on, specially when plans and ideas change along the way.Beware! This blog post may be a little unstructured, specially towards the end.The quarter as a wholeBefore the quarter commenced I was planning on adding TaskCluster jobs to Treeherder as my main objective. However, it quickly changed as GSoC submissions came around. We realized that we had two to three candidates interested in helping us. This turned into creating three potential projects. Two projects that came out of it are "refactor SETA and enable TaskCluster support" and "add unscheduled TaskCluster jobs to Treeherder." Both of these bring us closer to feature parity with Buildbot. Once this was settled, a lot of conversations happened with the TaskCluster team to make sure that Dustin's work and ours  lined up well (he’s worked on refactoring how the ‘gecko decision task’ schedules tasks).Around this time a project was completed, which made creating TaskCluster clients an excellent self-serve experience. This was key for me in reducing the number of times I had to interrupt the TaskCluster team to request that they adjust my clients.Also around this time, another change was deployed that allowed developer’s credentials to assume almost all scopes required to schedule TaskCluster tasks without an intermediary tool with power scopes. This is very useful to create tools which allow developers to schedule tasks directly from the command line with their personal credentials. I created some prototypes to prove this concept. Here’s a script to schedule a Linux 64 task. Here’s the blog post explaining it.During this quarter, Dustin refactored how scheduling of tasks was accomplished in the gecko decision task. For the project "adding new TaskCluster jobs," this was a risk as it could have made scheduling tasks either more complicated or not possible without significant changes. After many discussions, it seemed that we were fine to proceed as planned.Out of these conversations a new idea was born: the "action tasks" idea. The beauty of "action tasks" is that they're atomic units of processing that can make complicated scheduling requests very easy. You can read martianwars’ blog post (under “What are action tasks?”) to learn more about it. Action tasks are defined in-tree to schedule task labels for a push. The project as originally defined had a very big scope (goal: make Treeherder find action task definition and integrate them in the UI) and some technical issues were encountered that made me concerned that more would be encountered (i.e., limited scopes granted to developers; this is not an issue anymore). My focus switched to making pulse_actions requests be visible on Treeherder. When switching deliverables I did not realize that we could have taken the first part of the project and just implemented that.  In any case, a reduced scope is being implemented by martianwars since, after Dustin's refactoring, we need to put our graph through "optimizations" that determine which nodes need to be removed from the graph. This code lives in-tree and made "action tasks" to be the right solution since it uses in-tree logic where the optimizations code lives.While working on my deliverables, I also discovered various things and created various utility projects.New projectsTaskCluster developer experiments (prototypes):In this repository I created various prototypes that make scheduling tasks from the command line extremely easy.Repo: https://github.com/armenzg/TC_developer_scheduling_experimentsBlog post: Schedule Linux64 tasks from the command lineReplay pulse messages (new package):This project allows you to dump [...]



      Schedule a Linux64 TaskCluster task from the command line

      2016-05-17T16:57:22.229-04:00

      I've created an experimental repository to play with TaskCluster scheduling using your personal temporary credentials.

      If you want to try to schedule a real task from the command line feel free to give it a try:
      https://github.com/armenzg/TC_developer_scheduling_experiments


      Here's the output of scheduling a Linux64 debug task.
      NOTE: It will not post to Treeherder
      NOTE: It will open a new tab asking you to grant access to your TaskCluster temp credentials.

      (TC_scheduling) armenzg@armenzg-thinkpad:~/repos/TC_developer_scheduling_experiments$ python schedule_linux64_task.py 
      04:48:50 root Setting INFO level
      04:48:50 mozci.taskcluster.tc We're going to open a new tab and authenticate you with TaskCluster.
      -------------------------------------------------------
        Opening browser window to login.taskcluster.net
        Asking you to grant temporary credentials to:
           http://localhost:39025
      -------------------------------------------------------
      04:48:54 mozci.taskcluster.tc Inspect the task in https://tools.taskcluster.net/task-inspector/#bmt-5IqPTwmn8JrMzdofGg




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



      Installing Vidyo on Ubuntu 16.06 LTS (dependency libqt4-gui unmet)

      2016-05-06T12:21:11.955-04:00

      I've recently upgraded to Ubuntu 16.06 LTS from Ubuntu 14.04 LTS.The only package I've noticed to be missing is vidyodesktop.In order to install it, I tried going to v.mozilla.com and open the .deb file.Unfortunately, it would not install.In order to determine why it was failing I run this:sudo dpkg -i VidyoDesktopInstaller-ubuntu64-TAG_VD_3_3_0_027.deb Unfortunately it said that libqt4-gui needed to be installed, however. the package is not available for this version of Ubuntu.In order to fix it, rail told me that we had to install a dummy package to fool Vidyo. This can be accomplished with equivs package.Install equivs packagesudo apt-get install equivsGenerate a control fileequivs-control libqt4-guiEdit libqt4-gui and tweak the following variables: Package, Version, Description. Example file### Commented entries have reasonable defaults.### Uncomment to edit them.# Source: Section: miscPriority: optional# Homepage: Standards-Version: 3.9.2Package: libqt4-guiVersion: 4.8.1# Maintainer: Your Name # Pre-Depends: # Depends: # Recommends: # Suggests: # Provides: # Replaces: # Architecture: all# Multi-Arch: # Copyright: # Changelog: # Readme: # Extra-Files: # Files: # Description: fake package to please vidyo long description and info.  second paragraph Build the debequivs-build libqt4-guiInstall the debsudo dpkg -i libqt4-gui_4.8.1_all.deb This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.[...]



      Replay Pulse messages

      2016-05-03T15:52:11.202-04:00

      If you know what is Pulse and you would like to write some integration tests for an app that consumes them pulse_replay might make your life a bit easier.

      You can learn more about by reading this quick README.md.


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



      Open Platform Operations’ logo design

      2016-05-02T13:45:30.447-04:00

      Last year, the Platform Operations organization was born and it brought together multiple teams across Mozilla which empower development with tools and processes.

      This year, we've decided to create a logo that identifies us an organization and builds our self-identify.

      We've filed this issue for a logo design [1] and we would like to have a call for any community members to propose their designs. We would like to have all applications in by May 13th. Soon after that, we will figure out a way to narrow it down to one logo! (details to be determined).

      We would also like to thank whoever made the logo which we pick at the end (details also to be determined).

      Looking forward to collaborate with you and see what we create!

      [1] https://github.com/mozilla/Community-Design/issues/62


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



      The Joy of Automation

      2016-04-22T10:26:54.787-04:00

      This post is to announce The Joy of Automation YouTube channel. In this channel you should be able to watch presentations about automation work by Mozilla's Platforms Operations. I hope more folks than me would like to share their videos in here.

      This follows the idea that mconley started with The Joy of Coding and his livehacks.
      At the moment there is only "Unscripted" videos of me hacking away. I hope one day to do live hacks but for now they're offline videos.

      Mistakes I made in case any Platform Ops member wanting to contribute want to avoid:

      • Lower the music of the background music
      • Find a source of music without ads and with music that would not block certain countries from seeing it (e.g. Germany)
      • Do not record in .flv format since most video editing software do not handle it
      • Add an intro screen so you don't see me hiding OBS
      • Have multiple bugs to work on in case you get stuck in the first one



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



      Project definition: Give Treeherder the ability to schedule TaskCluster jobs

      2016-04-17T12:01:38.659-04:00

      This is a project definition that I put up for GSoC 2016. This helps students to get started researching the project.The main things I give in here are:BackgroundWhere we came from, where we are and we are heading towardsGoalUse case for developersBreakdown of componentsRather than all aspects being mixed and not logically separateNOTE: This project has few parts that have risks and could change the implementation. It depends on close collaboration with dustin.-----------------------------------Mentor: armenzg IRC:   #ateam channelGive Treeherder the ability to schedule TaskCluster jobsThis work will enable "adding new jobs" on Treeherder to work with pushes lacking TaskCluster jobs (our new continuous integration system). Read this blog post to know how the project was built for Buildbot jobs (our old continous integration system).The main work for this project is tracked in bug 1254325.In order for this to work we need the following pieces:A - Generate data source with all possible tasksBug 1232005 - Let the gecko decision task generate a file with all the possible TaskCluster jobs that could have been scheduled for a given pushWe will need to post this artifact into the TC index so we can fetch itWe will probably need to create a "latest" aliasRISK: The structure of graphs is going to change; the artifact will change in format:https://bugzilla.mozilla.org/show_bug.cgi?id=1178516graph-generation detailsAlternative mentor for this section are: garndt B - Teach Treeherder to use the artifactFetch that artifact for every tree and update the "runnable api"RISK: The structure of graphs is going to change; the artifact will change in format:https://bugzilla.mozilla.org/show_bug.cgi?id=1178516graph-generation detailsThis will require close collaboration with Treeherder engineersThis work can be done locally with a Treeherder instanceIt can also be deployed to the “staging” version of Treeherder to do testsAlternative mentors for this section is: camdC - Teach pulse_actions to listen for requests from Treeherderpulse_actions is a pulse listener of Treeherder actionsYou can see pulse_actions’ workflow in hereOnce part B is completed, we will be able to listen for messages requesting certain TaskCluster tasks to be scheduled and we will schedule those tasks on behalf of the userRISK: Depending if the TaskCluster actions project is completed on time, we might instead make POST requests to an APIThis work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



      Project definition: SETA re-write

      2016-04-17T11:54:49.134-04:00

      As an attempt to attract candidates to GSoC I wanted to make sure that the possible projects were achievable rather than lead them on a path of pain and struggle. It also helps me picture the order on which it makes more sense to accomplish.It was also a good exercise for students to have to read and ask questions about what was not clear and give lots to read about the project.I want to share this and another project definition in case it is useful for others.----------------------------------We want to rewrite SETA to be easy to deploy through Heroku and to support TaskCluster (our new continuous integration system) [0].Please read carefully this document before starting to ask questions. There is high interest in this project and it is burdensome to have to re-explain it to every new prospective student.Main mentor: armenzg (#ateam)Co-mentor: jmaher (#ateam)Please read jmaher’s blog post carefully [1] before reading anymore.Now that you have read jmaher’s blog post, I will briefly go into some specifics.SETA reduces the number of jobs that get scheduled on a developer’s push.A job is every single letter you see on Treeherder. For every developer’s push there is a number of these jobs scheduled.On every push, Buildbot [6] decides what to schedule depending on the data that it fetched from SETA [7].The purpose of this project is two-fold:Write SETA as an independent project that is:maintainablemore reliableautomatically deployed through Heroku appSupport TaskCluster, our new CI (continuous integration system)NOTE: The current code of SETA [2] lives within a repository called ouija.Ouija does the following for SETA:It has a cronjob which kicks in every 12 hours to scrape information about jobs from every pushIt takes the information about jobs (which it grabs from Treeherder) into a databaseSETA then goes a queries the database to determine which jobs should be scheduled. SETA chooses jobs that are good at reporting issues introduced by developers. SETA has its own set of tables and adds the data there for quick reference.Involved pieces for this project:Get familiar with deploying apps and using databases in HerokuHost SETA in Heroku instead of http://alertmanager.allizom.org/seta.htmlhttps://bugzilla.mozilla.org/show_bug.cgi?id=1253020Teach SETA about TaskClusterhttps://bugzilla.mozilla.org/show_bug.cgi?id=1243123Change the gecko decision task to reliably use SETA [5][6]If the SETA service is not available we should fall back to run all tasks/jobsDocument how SETA works and auto-deployments of docs and HerokuWrite automatically generated documentationAdd auto-deployments to Heroku and readthedocsAdd tests for SETAAdd tox/travis support for tests and flake8Re-write SETA using ActiveData [3] instead of using data collected by Ouijahttps://bugzilla.mozilla.org/show_bug.cgi?id=1253028Make the current CI (Buildbot) use the new SETA Heroku servicehttps://bugzilla.mozilla.org/show_bug.cgi?id=1252568Create SETA data for per test information instead of per job information (stretch goal)On Treeherder we have jobs that contain testsTests re-order between those different chunksWe want to run jobs at a per-directory level or per-manifestAdd priorities into SETA data (stretch goal)Priority 1 gets every timePriority 2 gets triggered on Y push[0] http://docs.taskcluster.net/[1] https://elvis314.wordpress.com/tag/seta/[2] https://github.com/dminor/ouija/blob/master/tools/seta.py[3] http://activedata.allizom.org/tools/query.html[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1243123[5] https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=gecko[6[...]



      Improving how I write Python tests

      2016-04-13T15:26:46.694-04:00

      The main focus of this post is about what I've learning about writing Python tests, using mocks and patching functions properly. This is not an exhaustive post.What I'm writing now is something I should have learned many years ago as a Python developer. It can be embarrassing to recognize it, however, I've thought of sharing this with you since I know it would have helped me earlier on my career and I hope it might help you as well.Somebody has probably written about this topic and if you're aware of a good blog post covering this similar topic please let me know. I would like to see what else I've missed.Also, if you want to start a Python project from scratch or to improve your current one, I suggest you read "Open Sourcing a Python Project the Right Way". Many of the things he mentions is what I follow for mozci.This post might also be useful for new contributors trying to write tests for your project.My takeawayThese are some of the things I've learnedMake running tests easyWe use tox to help us create a Python virtual environment, install the dependencies for the project and to execute the testsHere's the tox.ini I use for mozciIf you use py.test learn how to not capture the outputUse the -s flag to not capture the outputIf your project does not print but instead it uses logging, add the pytest-capturelog plugin to py.test and it will immediately log for youIf you use py.test learn how to jump into the debugger upon failuresUse --pdb to using the Python debugger upon failureLearn how to use @patch and Mock properlyThe theory of how to mock is explained very well in "Using Mocks in Python"Learning where to @patch is golden. Read "Where to patch"How I write testsThis is what I do:If no tests exists for a module, create the file for itIf you're testing module.py create a test called test_module.pyIf you already have tests but want to add coverage to a function, determine what is the minimal py.test call to only call the test or set of testsYou don't want to run all tests when you're developingYou can read about it in "Specifying tests/selecting tests".@patch properly and use MocksWhat I'm doing now to patch modules is the following:What function are you testing? (aka test subject)Have a look at the function you're adding tests for and list which functions it calls (aka test resources)Which of those test resources do you need to patch?To patch the test resources I use @patch + I change the return_value. You can see an example in test_buildbot_bridge.py. I use two different style of patching if you're interestedI normally change test resources which hit the network (controlled environment) or that I can make the test execution fasterYou can have pieces of code that are shared between tests to avoid duplicating mocking codeDetermine if you need to Mock objects and function callsSee in here an example where I needed to mock a Push object The way that Mozilla CI tools is designed it begs for integration tests, however, I don't think it is worth doing beyond unit testing + mocking. The reason is that mozci might not stick around once we have fully migrated from Buildbot which was the hard part to solve.This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. [...]



      mozci-trigger now installs with pip install mozci-scripts

      2016-04-12T15:32:55.202-04:00

      If you use mozci from the command line this applies to you; otherwise, carry on! :)

      In order to use mozci from the command line you now have to install with this:
      pip install mozci-scripts
      instead of:
      pip install mozci

      This helps to maintain the scripts separately from the core library since we can control which version of mozci the scripts use.

      All scripts now lay under the scripts/ directory instead of the library:
      https://github.com/mozilla/mozilla_ci_tools/tree/master/scripts




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



      End of MozCI QoC term

      2016-02-02T09:48:37.176-05:00

      We recently completed another edition of Quarter of Contribution and I had the privilege to work with MikeLingF3real & xenny.
      I want to take a moment to thank all three of you for your hard work and contributions! It was a pleasure to work together with you during this period.

      Some of the highlights of this term are:

      You can see all other mozci contributions in here.

      One of the things I learned from this QoC term:
      • Prepare sets of issues that are related which build towards a goal or a feature.
        • The better you think it through the easier it will be for you and the contributors
        • In GitHub you can create milestones of associated issues
      • Remind them to review their own code.
        • This is something I try to do for my own patches and saves me from my own embarrassment :)
      • Put it on the contributors to test their code before requesting formal review
        • It forces them to test that it does what they expect it to do
      • Set expectations for review turn around.
        • I could not be reviewing code every day since I had my own personal deliverables. I set Monday, Wednesday and Friday as code review days.
      It was a good learning experience for me and I hope it was beneficial for them as well.



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



      Mozhginfo/Pushlog client released

      2015-11-26T10:17:46.746-05:00

      Hi,
      If you've ever spent time trying to query metadata from hg with regards to revisions, you can now use a Python library we've released to do so.

      In bug 1203621 [1], our community contributor @MikeLing has helped us release the pushlog.py module we had written for Mozilla CI tools.

      You can find the pushlog_client package in here [3] and you can find the code in here [4]

      Thanks MikeLing!

      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1203621
      [2] https://github.com/MikeLing
      [3] https://pypi.python.org/pypi/pushlog_client
      [4] https://hg.mozilla.org/hgcustom/version-control-tools/rev/6021c9031bc3


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



      Welcome F3real, xenny and MikeLing!

      2015-11-24T12:58:28.848-05:00

      As described by jmaher, we started this week our first week of mozci's quarter of contribution.

      I want to personally welcome Stefan, Vaibhav and Mike to mozci. We hope you get to learn and we thank you for helping Mozilla move forward in this corner of our automation systems.

      I also want to give thanks to Alice for committing at mentoring. This could not be possible without her help.


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



      Mozilla CI tools meet up

      2015-11-24T12:52:44.347-05:00

      In order to help the contributors' of mozci's quarter of contribution, we have set up a Mozci meet up this Friday.

      If you're interested on learning about Mozilla's CI, how to contribute or how to build your own scheduling with mozci come and join us!

      9am ET -> other time zones
      Vidyo room: https://v.mozilla.com/flex.html?roomdirect.html&key=GC1ftgyxhW2y


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



      Fixes for Sheriffs' Treeherder backfilling and scheduling support

      2015-10-19T12:46:17.759-04:00

      Sheriffs have the ability to backfill jobs on Treeherder (to determine the push where are regression starts) and the ability to run missing jobs on a push (due to coalescing/SETA).

      Few weeks ago we added alerts to pulse_actions:


       and we've fixed a couple of bugs since then:


      Other changes:




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