Confirmed users
9,511
edits
CI Automation: Difference between revisions
→What to Expect After Landing
(Make new test environment into a link) |
|||
| Line 129: | Line 129: | ||
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 you 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! | 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 you 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. | 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. | ||
If all the builds and tests pass on the integration branch, your patch will eventually be merged into mozilla-central (these merges typically happen twice a day). At this point you're in the clear! The next time someone pulls in the latest changes from central, your changes will be included. Congratulations! | If all the builds and tests pass on the integration branch, your patch will eventually be merged into mozilla-central (these merges typically happen twice a day). At this point you're in the clear! The next time someone pulls in the latest changes from central, your changes will be included. Congratulations! | ||