🚦 iBrowe Merge Policy & CI Gatekeeping Guidelines

To maintain build stability and minimize disruptions, follow these strict rules before merging any changes into the ibrowe-core or ibrowe-browser repositories.

✅ CI Checks Before Merge

Only merge if the Jenkins CI pipeline reports success on the pull request.

  • If you’re unsure how to read Jenkins CI results, ask a lead engineer or seek onboarding from @mihaiplesa
  • Pull requests from forks must be cherry-picked into a local branch on ibrowe-core or ibrowe-browser to trigger CI jobs
  • No visible CI? ➜ It’s likely the branch is still on a fork

❌ Immediate Reverts

If something lands and breaks CI or test results, revert it immediately:

  • Do not wait to discuss with the author
  • Re-open the original issue tied to the breaking PR
  • If you accidentally break the build: own it, apologize, and help others when they break something

🔁 Merge Readiness Checklist

  1. CI pipeline passes (ibrowe_unit_tests, ibrowe_browser_tests, audit-deps, test-security)
  2. Your branch is not closed — check the topic of #ibrowe-core Slack channel
  3. Jenkins CI status is green for your PR

🔧 Common Tree Breakage Scenarios

🔹 Outdated Dependencies

  • If you fix something like npm audit, don’t forget to update the DEPS file accordingly
  • Each release channel requires its own DEPS bump

🔹 Out-of-date Local Tree

  • Before reverting, run:
npm run sync
npm run apply-patches
  • Check if the latest PR already fixed the issue

🔹 Updated 3rd-party Components

  • Upstream changes may introduce:

    • Broken URLs
    • Test failures (especially test-security)

  • Create an issue and consider adding a proxy if a remote resource has changed unexpectedly

🚨 What Triggers a Tree Closure?

Tree is considered closed when any of the following fails:

  • ibrowe_unit_tests
  • ibrowe_browser_tests
  • npm run audit-deps
  • npm run test-security
  • Jenkins CI pipeline failures

🤯 Why So Strict?

  • If the main tree is broken, every CI job on every PR fails
  • It causes wasted engineering time across the team
  • Blocks QA and release cycles
  • Reverts become much harder once broken code has more commits layered on top

📎 Source: Reworked from Brave’s internal CI/merge policy documentation — adapted and branded for iBrowe’s development process