Skip to content

Latest commit

 

History

History
29 lines (26 loc) · 2.7 KB

SERVERVENDORING.md

File metadata and controls

29 lines (26 loc) · 2.7 KB
Raw

How to vendor Tools changes into Server Repo

N.B. We are no longer vendoring tools to server master. Only vendor to v4.2, v4.0, and v3.6. Vendoring to v4.0 and v3.6 should only be done for critical/security issues.

Vendoring Tools into Server is relatively straightforward:

  • Cherry-pick the required commits into the "vX.Y-master" branch. Run Evergreen patch build and make sure all the tests passed. Then create a PR and paste the evergreen link in the description.

  • After the PR is approved and merged, for any Tools branch to vendor to server, merge the "vX.Y-master" branch into "vX.Y", or some intermediate point. (E.g. v4.2-master is the tip of v4.2 backports, but v4.2 trails behind and is the "stable" v4.2 branch that will be merged to server v4.2).

    You should create another Pull request for the merging. But remember since Github doesn't support fast forward option in merge, after the PR is approved, please close the PR and manually merge by running following command in vX.Y branch. Then check these two branches are identical before pushing.

    git merge --ff-only vX.Y-master

  • Push “vX.Y” branch

  • Update (git pull) the kernel tools repository (these instructions assume it's located at ~/git/mongo/kernel-tools

  • Navigate to the mongodb server repo

  • Checkout the branch you want to import into and make sure it's pulled to the latest head (examples, "v4.2", "v4.0", "v3.6", etc.)

  • Execute ~/git/mongo/kernel-tools/vendoring/import_vendor_branch.py tools to import tools; this will leave you in an editor for a commit message
    Note: if you have your origin remote set to [email protected]:mongodb/mongo, this will not work. It must be set to [email protected]:mongodb/mongo.git because the script checks that string for direct equality.

  • Make sure to git fetch the tools remote.

  • Tidy up the commit message if you want
    IMPORTANT: Remove any commits that aren't actually resolved in the TOOLS -- e.g. turning off tests pending a later fix

  • Also remove any commits for tickets that were already "released" (i.e. tagged to a previous server version)

  • Check whether etc/evergreen.yml needs any changes due to changes in the build system

  • Generally this is no longer needed now that everything uses set_gopath.sh

  • Patch build the "bang" (!) build variants for the "tool" tasks. E.g.:

    evergreen patch -p mongodb-mongo-v4.2

    Note: you will likely need to set upstream: git branch --set-upstream-to origin/v4.2

  • If the patch build works, rebase and queue the commit

    git pull --rebase
    evergreen commit-queue merge --project mongodb-mongo-v4.2

  • After the commit is accepted, update the fix versions on the tools tickets.