CI Automation: Difference between revisions

We work on a wide range of projects around Mozilla's core [https://en.wikipedia.org/wiki/Continuous_integration continuous integration] (CI) pipeline. Some areas we focus on include:

* '''Performance''': developing perf harnesses and standing up new benchmarks/measurements

* '''Data''': collecting CI related data, creating metrics and dashboarding

* '''Configuration''': developing taskgraph and modifying which tasks run in CI

* '''#ci''': General channel for CI related discussion

There are so many different aspects to contributing that implementing the patch is often the easy part! This is a high level overview of the contribution process, with links to resources that go into greater detail for each step.

After cloning the source one of the most common first tasks is building Firefox. While the work our team tends to do rarely requires a build, it's still a good step to help familiarize yourself with the repository and some of the tools we use.

Follow [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build these instructions] to setup your dependencies and perform a build (note: if you've already cloned, you can run '''./mach bootstrap''' instead of downloading bootstrap.py). Once your build is finished, use '''./mach run''' to spin up your very own Firefox!

When going through this process, you'll notice that you'll interact a lot with [https://firefox-source-docs.mozilla.org/python/mach/index.html mach]. Mach is a command line dispatcher that we use to provide a central entry point to a vast array of tools. You can look through '''./mach help''' to get a sense of all the different tasks that can be performed in the repository.

Find a string in Firefox (e.g in one of the menus or preference dialogs) and make sure that it's fairly unique. Then try and use [https://searchfox.org/mozilla-central/source searchfox] to find where that string is defined. Change the value to something else and re-run a build. Then use '''./mach run''' to see if your change is there!

See [https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/ Mercurial For Mozillians] for more information on Mercurial.

Mozilla has a multi-tiered branching system (in reality each branch is a separate repository, but let's gloss over that fact for now). As we mentioned earlier, all mainline development happens on mozilla-central. Since we are all human, every so often we accidentally land something that causes things to break (e.g we might cause a test to fail). Now imagine that developers were landing their patches directly on mozilla-central and occasionally causing things to break. If you were developing your own patch and notice a test failure it would be really hard for you to determine whether your patch was to blame, or if I just happened to be based on someone else's change that caused it to break. At a scale of hundreds of developers it's not hard to imagine how this would get out of hand very quickly!

Instead Mozilla uses something called an "integration branch". These are branches where it's *ok* if things get broken since no one bases their local work on top of them. If your change breaks something, you'll get "backed out" (i.e the exact reverse of your commit will be committed). In this scenario, someone will comment on the bug to notify you of the backout and it will be your (and your mentor's) responsibility to figure out what failed and how to fix. Again don't feel bad if this happens, it's a normal part of our workflow.