Today I was suddenly reminded of a question I saw somewhere a couple weeks back. I wasn’t going to admit it at first, but it was on Stack Overflow. I actually went looking for the question, but can’t seem to find it, so here’s my version of the story from memory.
The question basically said that after every commit to a code base, it would trigger a build on their build server. The build generated a file (I think it was called revision.txt) that was tagged with the current revision number, and then checked back into source control, which would then trigger a build, which would generate a file……. and so on.
I was so focused on the fact that they would be generating something that could be retrieved at any point in time from the repository that I failed to see the value of what was really being asked. I the fact that you would create a file with a revision number, and check it into the repository, effectively nullifying that revision number was so consuming for me that I didn’t stop to think that it might actually be helpful to not build on every commit.
Then this morning I was working on some test documentation for a deployment that we’re doing soon. As I made changes and checked them into the repository, I kept triggering builds. Then it hit me. I realized that there’s really no reason why a test doc that has nothing to do with a the build. I mean, in this case, the build doesn’t take long, but we have some pretty big projects here that can really hit our build server hard (which causes emails to be sent out to our server admins).
It didn’t take me long to find the Filtered Source Control Block and update our configuration to use it.
But it got me thinking. Though I don’t fully agree with the process being described in the original question, I was so focused on what was wrong that I completely missed out on learning about what was actually a valid, useful and soon-to-be relevant feature in my build server.