workflow.md

1. check out
2. build
3. run
4. kick off feature
   1. branching
   2. code
   3. debug
   4. kick off code reviewing
      1. upload
      2. sync
      3. OWNERS
      4. branching from branch
   5. clean

Checking out

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH="$PATH:/path/to/depot_tools"
export PATH="$PATH:${HOME}/depot_tools"
mkdir ~/chromium && cd ~/chromium
fetch --nohooks chromium
cd src
./build/install-build-deps.sh
gclient runhooks 
gn gen out/Default 

Hacking

Building

autoninja -C out/Default chrome

Running

out/Default/chrome

Branching

git checkout master
git checkout -b feature

Coding

// hack hack hack 
git commit -a -m ''

Reviewing

Here is my workflow for code reviewing:

1. upload
2. start review
3. get feedback
4. code, go back to step (1)
5. kick off, go back to step (1)
6. sync, go back to step (1)
7. get [OWNERS](#owners), go back to step (1)
8. submit using the gerrit UI

Uploading

git cl format
git cl upload

Address feedback, hack hack hack and go back to the previous step.

Once the feedback is resolve, sync to a more recent point in the codebase.

Sync

git checkout master
git pull
git checkout feature
git merge master
gclient sync

Hack hack hack to address build and tests queue, and sync again.

OWNERS

Address owernship approvals:

git cl owners

Branching from branch

Often, you run into feedback on code reviews that is worth de-coupling into a separate changelist: things that you'd like to do (i.e. feedback is directionally correct, e.g. refactorings or better test coverage) but don't want to block your submission on (i.e. tactically, you want to de-couple the steps, e.g. your cl is getting big, it blocks other team mates, it blocks manual testing on canaries, etc).

A powerful way you can go about this is to branch from your current branch, and kick off a changelist that starts from where you are working.

It helps to unblock yourself by:

• enabling your cl to the submitted
• being able to work on top of a cl that is still in progress / under review

It helps your reviewer by:

• showing your are serious about addressing their feedback
• showing that it is an orthogonal change
• showing that it can increase substantially your cl size (e.g. it makes it harder to go through the CQ, get approvals and/or )

To start, branch off from your existing branch, say feature-base, using the vanilla git branch command:

git branch
* master
[*] feature-base

git checkout -b feature-new

hack hack hack and send it for review:

git cl upload

You can go back and forth between branches as your review progresses. Once feature-base is submitted, you want to merge it into master by pulling from HEAD.

# move back to master
git checkout master
# pull from upstream
git pull
# pull submodules
gclient sync

Your master should now contain the submitted changelist of feature-base. Once that's the case, jump into your branch and merge it.

# jump into your branch of a branch
git checkout feature-new
# merge with master
git merge master
# sets upstream to master so that git cl upload doesn't complain
git branch --set-upstream-to=master
# sanity check that your changes seem correct with regards to upstream
git diff origin/master
# upload the rebase
git cl upload

From here, I typically use the CQ in the gerrit UI to submit the CL.

More info here:

Rebasing two branches

Say you were working on two features:

master
|- a
|- b

And it turns out that feature b depends on feature a, which you'd like to turn into:

master
|- a
   |- b

You can rebase b into a to accomplish this.

git checkout b
# turn all commits in branch b into a single commit
git reset --soft master
git add -A && git commit -m "squashing"

Now, your branch "b" is ahead of "master" by a single commit, which should make rebasing simpler:

git rebase a

Now, resolve the conflicts between a and b and commit.

To fix gerrit's parent relationship, you want to:

git branch --set-upstream-to=a

Deleting merged branches

git branch --merged | egrep -v "(^\*|master|dev)" | xargs git branch -d

Cleaning

Sometimes you need to clean your build (e.g. there are generated files that are not relevant anymore).

You can use the following:

gn clean out/Default

Common Tests

Global Interface Listing

autoninja -C out/Default image_diff 
third_party/blink/tools/run_web_tests.py -t Default third_party/blink/web_tests/webexposed/global-interface-listing.html

Another example:

third_party/blink/tools/run_web_tests.py -t Default third_party/blink/web_tests/external/wpt/credential-management/fedcm-logout-rps.https.html

Debugging:

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/testing/web_tests.md

// Run http server
third_party/blink/tools/run_blink_wptserve.py -t Default

Run the local chromium build with the right flags:

    {
      "label": "run chrome",
      "type": "shell",
      "command": "${workspaceFolder}/out/current_link/Chromium.app/Contents/MacOS/Chromium",
      "args": ["--use-mock-keychain", "--disable-features=DialMediaRouteProvider", "--enable-blink-features=MojoJS,MojoJSTest"]
    }

And then load the test:

http://localhost:8081/credential-management/fedcm-logout-rps.https.html