Day 34: A Hook That Cannot Fail, and an Error Three Commands From Its Cause

Day 34's theme revolves around failures that are reported elsewhere than where they occurred. An example is a Git hook with incorrect permissions that fails to execute and provides no indication of the failure. Another example involves a heredoc with an extra trailing space, which creates an error about a missing zip file, three commands downstream from the initial issue.

The hook in question is a post-update hook that automatically generates a release tag every time a push is made to the master branch in the KodeKloud Engineer platform. The hook's script checks each ref that has been updated and, if it is the master branch, it generates a tag using the current date and the commit hash. To ensure idempotency, any error messages related to the tag generation are redirected to /dev/null.

However, it is important to note that post-update hooks run after the ref updates have already occurred, so they cannot reject bad pushes. Instead, pre-receive or update hooks should be used for such validation. Additionally, the script must have the execute bit set, otherwise it will be ignored silently. When a hook is required to run on the server rather than the client, it must be placed on the server directly.

The last lesson from the Git tasks is to verify the output of each command rather than simply relying on the exit code. For instance, after creating a Lambda function, it is crucial to use the wait function command to ensure the function is active and available for invocation.