I was learning about repo, and noted that repo can use a “list of projects” to narrow down the scope of its actions. It will operate on the list of projects you give it, and not the others. But, as a newish member of the team, I didn’t know what the list of projects was. I knew there was a manifest file. It is in xml format.
I was never very successful with xml. However, I thought that time has passed, and maybe there is a newer easier to use tool out there. I looked again and found xmlstarlet. Maybe my previous attempts at xml have softened me up so I can understand xmlstarlet, or maybe it really is easier than previous xml tools.
I wanted an xmlgrep:
xmlstarlet sel -t -m "//project" -v "@path" -n default.xmlcontinue reading
03/19: android: what changed?
Our nightly builds started failing a while ago, and we wanted to know why. Nothing was immediately obvious so, as a new member to the team, I wanted to see what was different between “day that it worked” and “day that it failed”. Or rather, as the builds fixed themselves after a few days, what was the difference between “day that it failed” and “day that it worked”.
Well the android build is made up of a bunch of subprojects, each with its own git repository. I wasn’t going to be cd into each directory and running “git log” to see if something changed there lately. So I learned about the “forall” subcommand in repo:
repo forall -c "pwd; git log | grep '^[dD]ate' | head -1" > /tmp/repo-last-update-16and again in the other build directory.
A little massaging of the outputs allowed me to compare them with diff and find a differing project.