Taskcluster Github is the Taskcluster service responsible for kick starting tasks on
Github repositories. At a high level:
- You install a Taskcluster app from the Github marketplace.
- This app sends webhooks to the Github service.
- Upon receiving a webhook, the Github service processes your repository’s .taskcluster.yml
file.
- The Github service schedules tasks (if any) and updates the Github checks suite, or comments on
your push / pull-request if there is an error.
While the service itself is relatively simple, testing it locally can be a pain! One approach might
be to try and synthesize Github’s webhook events, and then intercept the network requests that the
Github service makes in response. But this is tricky to do, and without actually seeing the
results in a proper Github repo, it’s hard to be sure that your changes are working as intended.
Ideally you would have a real repo, with a development version of the app listed in the Github
Marketplace, hooked up to a Taskcluster Github service running on your local machine. This way you could
trigger webhooks by performing real actions in your repo (such as opening a pull-request). Better
yet, you could see exactly how your Github service changes react!
Thanks to a lot of great work from Yarik, this is easier than ever and is all documented (or linked
to) from this page. If you are already familiar with Taskcluster development, or enjoy figuring
things out yourself, you may wish to skip this post and read the docs instead. But if you are a
Taskcluster newbie, and would appreciate some hand holding, follow along for a step by step tutorial
on how to work on and test Taskcluster Github!
Read more →Introducing taskgraph --diff
to help validate your task configuration changes.
Read more →Last time we looked at some
ways reviewers can keep the review process moving efficiently. This week, let’s put on our author
hats and do the same thing.
Read more →In the next two posts we will examine the etiquette of using Phabricator. This post will examine
tips from the reviewer’s perspective, and next week will focus on the author’s point of view.
While the social aspects of etiquette are incredibly important, we should all be polite and
considerate, these posts will focus more on the mechanics of using Phabricator. In other words, how
to make the review process as smooth as possible without wasting anyone’s time.
Let’s dig in!
Read more →If it ain’t broke don’t fix it.
This old addage is valuable advice that has been passed down through
generations. But it hasn’t stopped these people from rewriting command line
tools perfected 30+ years ago in Rust.
This week we’ll take a quick look at exa, a replacement for ls
. So why
should you ignore the wise advice from the addage and replace ls
? Because there are marginal
improvements to be had, duh! Although the improvements in this case are far from marginal.
Read more →Following up last week’s post on some mach try
fundamentals, I figured it would be worth posting some actual concrete tips and tricks. So
without further ado, here are some things you can do with ./mach try
you may not have known about
in rapid fire format.
Read more →There is a lot of confusion around mach try
. People frequently ask “How do I get task X in mach
try fuzzy?” or “How can I avoid getting backed out?”. This post is not so much a tip, rather an
explanation around how mach try
works and its relationship to the CI system (taskgraph). Armed
with this knowledge, I hope you’ll be able to use mach try
a little more effectively.
Read more →Mozilla developers often need to juggle multiple build configurations in their day to day work.
Strategies to manage this sometimes include complex shell scripting built into their mozconfig, or a
topsrcdir littered with mozconfig-*
files and then calls to the build system like
MOZCONFIG=mozconfig-debug ./mach build
. But there’s another method (which is basically just a
variant on the latter), that might help make managing mozconfigs a teensy bit easier:
mozconfigwrapper.
In the interest of not documenting things in blog posts (and because I’m short on time this
morning), I invite you to read the README file of the repo for installation and usage instructions.
Please file issues and don’t hesitate to reach out if the README is not clear or you have any
problems.
Read more →Have you ever submitted a patch to Phabricator only to have reviewbot reveal dozens of lint errors
all over? Or worse yet, have you landed before reviewbot had a chance to analyze your patch and been
backed out over lint failures? If so fear not, we’ve all been there. Still, it’s hard not to feel a
little embarrassed when it happens. Luckily for you, it’s pretty easy to eliminate the possibility
of it ever happening again!
Read more →I first joined Mozilla as an intern in 2010 for
the “Tools and Automation Team” (colloquially called the “A-Team”). I always had a bit of
difficulty describing our role. We work on tests. But not the tests themselves, the the thing that
runs the tests. Also we make sure the tests run when code lands. Also we have this dashboard to view
results, oh and also we do a bunch of miscellaneous developer productivity kind of things. Oh and
sometimes we have to do other operational type things as well, but it varies.
Over the years the team grew to a peak of around 25 people and the A-Team’s responsibilities
expanded to include things like the build system, version control, review tools and
more. Combined with Release Engineering (RelEng), this covered almost all of
the software development pipeline. The A-Team was eventually split up into many smaller
teams. Over time those smaller teams were re-org’ed, split up further, merged and renamed over and
over again. Many labels were applied to the departments that tended to contain those teams. Labels
like “Developer Productivity”, “Platform Operations”, “Product Integrity” and “Engineering
Effectiveness”.
Interestingly, from 2010 to present, one label that has never been applied to any of these teams is
“DevOps”.
Read more →