Deep Work, PR Review, and Git Hashes
This week I'm starting a new practice to capture my weekly thoughts and notes and write them up in a weekly blog post. We'll see how it goes!
This week I finished reading through Deep Work and the previous week I had finished Atomic Habit. Both of these books were apart of a larger path I've been on to find more focus and productivity in the work that I do during that day and outside of it. While Atomic Habits wasn't nearly as useful as Deep Work, I think they both provided some good footing for improving your work-life and are worth the read. My main take aways are
All in all they're worth the read - hopefully I see some positive impacts in the near future.
At work this week it's been a whirlwind of PR reviews. I've been working with my team to create a better review process to ensure code is consistent across projects and teams. This is especially important, I've found, with languages like C# where Visual Studio can hide a lot of complexity and lead to inconsistent environments and failed builds. I've probably done 4 or 5 PR reviews this week and am struggling to identify why it's becoming such a difficult process.
Ultimately the problem comes down to the fact that a PR review is too late for some many code quality changes. A lot of the problems in our team can be boiled down to a few categories
While 1 is easily implemented as a CI check and I'm sure there's some automated solutions around #2, #3 really is a bigger culture issue than it is a code issue. To have an effective PR Review process, I'm starting to think there's a few things that need to come first.
After nearly 6 months of work, I finally got a working beta of Mealie out the door for the v1 rewrite. As apart of the rewrite I'm trying to adopt a more Agile mindset and ship small more incremental changes - especially within the context of the beta. I don't want to have to bump a version number every time something tiny changes. The solution here is to package a build ID with the docker container so I can easily differentiate images that have the same tag. How do I do this though?
Build Args was an easy solution to this problem. Surpassingly easy. First, when running
docker build you need to provide the argument so it can be read from the dockerfile.
--build-arg COMMIT=$(git rev-parse HEAD)
This snippet will capture the latest git commit hash and apply it as the argument
COMMIT. Then all you need to do is capture it in the dockerfile and it's available in the
env of your container.
ARG COMMIT ENV GIT_COMMIT_HASH=$COMMIT
Now you can use that to display the Build ID in your UI or where-ever you need it.