LDAP_BIND_PASSWORD environment variables in the system (e.g. when creating your Docker container, etc).
|Start-Date: 2018-11-19 14:23:29|
|Commandline: apt-get -y install less vim|
|Install: vim-common:amd64 (2:8.0.0197-4+deb9u1, automatic), vim-runtime:amd64 (2:8.0.0197-4+deb9u1, automatic), vim:amd64 (2:8.0.0197-4+deb9u1), xxd:amd64 (2:8.0.0197-4+deb9u1, automatic), libgpm2:amd64 (1.20.4-6.2+b1, automatic), less:amd64 (481-2.1)|
|End-Date: 2018-11-19 14:23:37|
|Start-Date: 2018-11-19 14:25:58|
|Commandline: apt-get remove vim|
|Remove: vim:amd64 (2:8.0.0197-4+deb9u1)|
|End-Date: 2018-11-19 14:25:59|
PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.
Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories
Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.
Services declared as
oneshot are expected to take some action and exit immediatelly (thus, they are not really services,
no running processes remain). A common pattern for these type of service is to be defined by a setup and a teardown action.
Let's create a example
foo service that when started creates a file, and when stopped it deletes it.
Create executable file
|DESCRIPTION="bad things™ are happening"|
|if [ $# -ne 3 ]; then|
|echo "Usage: pd-event.sh [TYPE] [SERVICE KEY] [INCIDENT KEY]"|
|echo " - TYPE: [t]rigger | [a]cknowledge | [r]esolve"|
|echo " - SERVICE KEY: unique identifier for service"|