CI Automation

Welcome to the CI Automation team's landing page!

We work on a wide range of projects around Mozilla's core continuous integration (CI) pipeline. Some areas we focus on include:

• Performance: developing perf harnesses and standing up new benchmarks/measurements
• Testing: developing test harnesses and improving test stability
• Data: collecting CI related data, creating metrics and dashboarding
• Configuration: developing taskgraph and modifying which tasks run in CI
• Tools: developing the tools that Firefox core developers use to interact with CI
• Plus many other projects

Contact Us

We hang out on irc.mozilla.org in the #cia channel. Feel free to drop by and say hello, we're a friendly bunch. Here are some related channels that might also be of interest:

• #ateam: General automation channel where all automation related teams across Mozilla hang out
• #ci: General channel for CI related discussion
• #cia: Our team channel
• #developers: Channel where developers all across Mozilla hang out
• #introduction: Channel where newcomers can ask questions around contributing, processes, or anything

Note on IRC communication

While IRC may appear to be a real-time communication channel, it is also used for asynchronous communication. Many people connect over persistent servers and will appear online even when away from their computers. Or sometimes they are simply busy at the moment and will respond when they have time. It's also easy for a question to get missed in a busy channel. So don't be discouraged if you don't get a response right away and don't be afraid to ask again at a later time.

Contributing

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.

Finding a Bug

The best way to find a bug is to ask us on IRC! Many of us have tasks set aside just for this purpose. But Mozilla also has several tools to help you find good bugs to work on:

• Codetribute
• What can I do for Mozilla?
• [good first bug] whiteboard tag in Bugzilla
• Mentored bugs in Bugzilla

Generally all issue tracking happens in Bugzilla, so this is one of the first accounts you'll need to make. In order to use some advanced integrations (like our review tool), you'll need to enable multi-factor authentication in your Preferences.

Finding the Source Code

Once you've been assigned a bug by someone (you won't have permission to do this yourself initially), you'll need to grab the source code. Most of Mozilla's code lives in a monorepo called "mozilla-central" (often abbreviated "central" or "m-c"). This is a Mercurial repository that lives on hg.mozilla.org.

You can use either Mercurial or Git to interact with the repository. Though Git support requires that you install a special library called git-cinnabar. While we do try to support git with cinnabar as much as possible, there might be workflows that don't work as nicely as their Mercurial counterparts.

Here are some resources to help you get set up with the source code:

• Getting the source code with Mercurial
• Mercurial for Mozillians
• A git workflow for Gecko development

Building Firefox

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 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 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.

Bonus Challenge

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 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!

Fixing the Bug

Now that you have the source and have familiarized yourself with the repo a bit, it's time to fix the bug! You can use any platform or editor that you want. If you get stuck, don't be shy to ask for clarification. IRC, the bug or e-mail are all appropriate places to ask.

Once you have your fix commit it with a message that follows Mozilla's guidelines. Be sure to test your patch (ask your mentor if instructions for testing weren't included in the bug). You should also run mach lint --outgoing to make sure you didn't cause any lint errors. If the patch is complicated enough, your mentor might also want to do a try push (you won't have permission to do this on your own, so they'll do it on your behalf).

Glossary

Mozillians use a dizzying amount of terminology that can make any new contributor's head spin. You'll often be able to find what you're looking for in the Glossary. If you come across something not mentioned there, feel free to ask us in IRC (and remind us to add it to the list).