DEV Community: Rafael Almeida

Managing multiple Git configurations

Rafael Almeida — Wed, 25 Nov 2020 15:20:31 +0000

Using the same computer for both work-related and personal projects may cause you to write Git commit messages with your private email on your work projects or vice-versa. That is assuming that you configured Git with the --global flag, which applies the configs to every repo on your OS user account.

But, what if there was an easy way to separate your Git configs, whether you're dealing with private or work repositories, accordingly? I have great news for you: if you're using Git with, at least, version 2.13, you can have Conditional Includes.

You might be wondering:

That's great. But how does it help me?

Worry no more!

The "middle" Git config level is the global one, which means that your configurations are stored on a ~/.gitconfig file.

Wondering how that file looks? Here's mine:

~
▶ cat .gitconfig
[user]
 signingkey = C9KF0E358V41E9C5
 name = Rafael Almeida
 email = rafaelcpalmeida@----.com
[gpg]
 program = gpg
[commit]
 gpgsign = true

Now, let's assume that I wanted to use:

The email rafaelcpalmeida@----.com with the GPG key C9KF0E358V41E9C5 on my private repositories.

and

The email rafael.almeida@company.com with the GPG key 9VKF4E35KV4LE935 on my work repositories.

That could be easily achieved by creating two new files: one with the configurations for your personal repositories and one for the work-related ones. Here are mines:

~
▶ cat .gitconfig_personal
[user]
 signingkey = C9KF0E358V41E9C5
 name = Rafael Almeida
 email = rafaelcpalmeida@----.com
~
▶ cat .gitconfig_company
[user]
 signingkey = 9VKF4E35KV4LE935
 name = Rafael Almeida
 email = rafael.almeida@company.com

Now, all I have to do is to reference them on my original .gitconfig file. Again, here's mine, now updated:

~
▶ cat .gitconfig
[gpg]
 program = gpg
[commit]
 gpgsign = true
[includeIf "gitdir:~/company/"]
 path = .gitconfig_company
[includeIf "gitdir:~/projects/"]
 path = .gitconfig_personal

The file above uses the configuration of each of the files but only if the path where the repository I'm interacting with matches the path specified on the configuration file.

Here's a demo:

~/company
▶ mkdir test && cd test
~/company/test
▶ git init
Initialized empty Git repository in /Users/rafaelalmeida/company/test/.git/
~/company/test master
▶ touch a
~/company/test master
▶ git add .
~/company/test master
▶ git commit -m "Testing git configs"
[master (root-commit) 6d5b06e] Testing git configs
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

Looking at my git log, the output I get is:

commit 6d5b06ef2678b921436b1c17a1d5684302c9a722 (HEAD -> master)
Author: Rafael Almeida <rafael.almeida@company.com>
Date: Tue Nov 24 00:30:21 2020 +0000
Testing git configs

Wondering what happens if I do the same on ~/projects? Here:

~/projects
▶ mkdir test && cd test
~/projects/test
▶ git init
Initialized empty Git repository in /Users/rafaelalmeida/projects/test/.git/
~/projects/test master
▶ touch a
~/projects/test master
▶ git add .
~/projects/test master
▶ git commit -m "Testing git configs"
[master (root-commit) 2ee78dc] Testing git configs
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

And here's my git log:

commit 2ee78dcd2d154ff227982ad2e04644dd98f64c6c (HEAD -> master)
Author: Rafael Almeida <rafaelcpalmeida@----.com>
Date: Tue Nov 24 00:33:30 2020 +0000
Testing git configs

And this is how you can manage different Git configurations without any fuzz. Want to share your feedback? Let me hear you in the comments below!

Seamless CI/CD with Jenkins + Helm and Kubernetes

Rafael Almeida — Wed, 02 Oct 2019 15:20:41 +0000

There are many ways and platforms you can use to solve CI/CD for your company nowadays. As we were already using Jenkins jobs for deployments and everyone at the team knew it well it was the obvious choice, but we shifted towards pipelines.

To implement this you need:

A Kubernetes cluster where you are going to deploy your applications
Helm deployment files for your application
Jenkins CI pipelines

The big picture

Jenkins will fetch branches and tags from the selected repository and run all steps defined for the pipeline inside your project's Jenskinsfile.

Kubernetes is an orchestration tool for containers so we need to be deploying applications as Docker containers so they can run and be managed inside this orchestration tool.

Helm is a “package manager” for Kubernetes. It reads, parses and injects values into a series of “Helm templates” that in the results in a series of Kubernetes objects. Helm then bundles all of these objects into a Helm release and installs it in the configured Kubernetes cluster. You can supply to helm some input values to configure each installation which is flexible enough to install for example the same application configured differently for multiple environments (e.g dev, staging, and production).

The jenkins pipeline

Here is an example of our declarative Jenkins pipeline file:

pipeline {
    agent {
        kubernetes {
            label 'my-app'
            yamlFile 'JenkinsKubernetesPod.yaml'
        }
    }
    stages {
        stage('Run unit tests') {
            steps {
              // The needed steps for your testing
            }
        }

        stage('Build application') {
            steps {
              // Build the app
            }
        }

        stage('Docker publish') {
            steps {
              // Publish a docker image for your application 
            }
        }

        stage('Deployment') {
            steps {
                script {
                  container('helm') {
                      // Init authentication and config for your kubernetes cluster
                      sh("helm init --client-only --skip-refresh")
                      sh("helm upgrade --install --wait prod-my-app ./helm --namespace prod")
                    }
                }
            }
        }
    }
}

You should include a file with the name “Jenkinsfile” in your project repository and Jenkins will use it to define the pipeline. For brevity, I only included the deployment step. In this step, you will call the Helm installation or upgrade. This will apply a helm upgrade to your previously installed Helm release or if no release exists Helm will execute a helm install with the given release name (e.g. prod-my-app).

It’s a good idea to include the namespace as prefix or suffix for the helm release name because release names are only a name for helm and not installed as part of a Kubernetes namespace.

If you attempt to install a release-dummy on namespace dev and a release-dummy on namespace staging it will fail because release-dummy will already exist and Helm doesn’t care about namespace. To solve this we include a prefix of the namespace on the release name.

The deployment file

Make sure you have configured your app to run as a Kubernetes Deployment or StatefulSet or avoid having downtime between deploys. Check the deployment.yaml helm template below:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-dp
spec:
  replicas: 2
  minReadySeconds: 60
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: {{ .Values.app.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.app.name }}
    spec:
      containers:
      - name: {{ .Values.app.name }}
        image: {{ .Values.app.image.repository }}/{{ .Values.app.image.name }}:{{ .Values.app.image.tag }}
        imagePullPolicy: Always
        envFrom:
        - configMapRef:
            name: config-{{ .Values.app.name }}
        ports:
        - name: http-{{ .Values.app.name }}
          protocol: TCP
          containerPort: 80

And that’s it, there are a lot of concepts to learn to put this all together but when you have it all covered up you will never have to put that much effort into deploying new applications and managing releases.

When you are done you push the commits into master or create a new tag and the code will appear in your servers without no more clicking.

How to use mongoDB with your Lumen API

Rafael Almeida — Mon, 12 Aug 2019 16:48:30 +0000

I’m currently building a RESTful API using Lumen, from the guys that brought to us Laravel. Lumen is a great micro-framework with most of the spectacular features from Laravel like Eloquent, caching, validation, routing, middleware and so on and so forth. The API I’m building it’s supposed to serve an, yet to develop, iOS app that it’s meant to support the information system of the college where I attend, which don’t correctly support mobile devices.

This would be a pretty straightforward project but unfortunately, they won’t make my life easy and won’t let me access the existing database. It sucks, right? However, they have a SOAP Web Service available that I can use. But… If I used their web service alongside my API every time I made a request it would take ages to get the information I’ve requested. This is, obviously, a shitty way to do things. So I’ve decided to implement a database where I can store the data by myself.

I’m fully aware that we shouldn’t repeat data but I can’t find a better way this time. I’ve decided to develop some Python bots that would periodically fetch information using the SOAP web service and store it in the database to be later served using the REST API. I’ve decided to use mongoDB mostly for its flexibility, performance, and scalability. I’m using mongo 3.4 so all the commands below are tested for this version.

So… How to setup Lumen to use mongoDB

Jens Segers has a wonderful Composer package to use mongoDB with Laravel: Laravel MongoDB. Looking at the repo instructions you can see that, for using with Lumen and after you installed the package, edit the file bootstrap/app.php and make it look like:

$app->register(Jenssegers\Mongodb\MongodbServiceProvider::class);

$app->withEloquent();

After this, you should create the config/database.php file and it’s contents are:

<?php
    return [
        'default' => 'mongodb',
        'connections' => [
            'mongodb' => [
                'driver' => 'mongodb',
                'host' => env('DB_HOST', 'localhost'),
                'port' => env('DB_PORT', 27017),
                'database' => env('DB_DATABASE'),
                'username' => env('DB_USERNAME'),
                'password' => env('DB_PASSWORD'),
                'options' => [
                    'database' => 'admin' // sets the authentication database required by mongo 3
                ]
            ],
        ],
        'migrations' => 'migrations',
    ];

This will override vendor/laravel/lumen/config/database.php and it will allow you to use mongo with your Lumen project. After this you have you change our .env file and append:

DB_CONNECTION=mongodb
DB_HOST=<dbHost>
DB_PORT=27017
DB_DATABASE=<dbName>
DB_USERNAME=<dbUser>
DB_PASSWORD=<dbUserPassword>

Out of the box mongo doesn’t have any authentication details. You can add your own user to it using:

use admin
db.createUser( { user: "<dbUser>",
          pwd: "<dbUserPassword>",
          roles: [ "userAdminAnyDatabase",
                   "dbAdminAnyDatabase",
                   "readWriteAnyDatabase"

] } )

Now I’m able to use Lumen’s artisan commands, for instance, I can create my users table using:

php artisan make:migration create_users_table --create=users

I’ve modified the migration file like:

public function up() {
    Schema::create('users', function (Blueprint $table) {
        $table->increments('_id');
        $table->string('username');
        $table->string('password');
        $table->timestamps();
    });
}

Now I can use php artisan migrate and I’ll see my newly created collection.

Using Ruby on Rails 5.2 Active Storage

Rafael Almeida — Tue, 06 Aug 2019 14:54:02 +0000

Active Storage, now bundled with Ruby on Rails 5.2, allows you to easily handle your file upload, either to cloud platforms, such as Amazon S3 or Google Cloud Storage, or even upload right into your application directory, linking your uploads to your Active Record models with ease.

In order to start using Active Storage, you should have an existing Ruby on Rails 5.2 or greater application (freshly installed or upgraded), open your terminal in your application directory and type the following command:

rails active_storage:install

This will generate a brand new migration for the two necessary database tables. After this, all you need to do is run the migrations with:

rails db:migrate

After this everything is ready to start using Active Storage.

Setting up

To start you should declare in your config/storage.yml file your Active Storage services, one for each service that you use in your application.

Please, note that for the sake of this article, I’ll just be showing configurations for uploading the files to the same directory as your application, in your local disk. If you prefer to use it to upload to any cloud provider please refer to the docs.

local:
    service: Disk
    root: <%= Rails.root.join("storage") %>

After you declared every service that you’ll be using it’s time to tell your application what service should be used on each environment. In this article, I’m going to configure my development environment to use my local storage service. In order to achieve this add the following line to config/environments/development.rb:

# Store files locally.
config.active_storage.service = :local

Use it

Now that we managed to configure Active Storage it’s time to start using it! One of the advantages of it is to easily create a relationship between the uploaded asset and your Active Record models, as stated at the beginning of this article, so we’re to take advantage of it. I have a Speakers model in which I intend to add an avatar to each of the speakers.

We’ll start by informing my Speakers model that it will have a one-to-one relationship with the corresponding uploaded avatar. My model will look like:

class Speaker < ApplicationRecord
    has_one_attached :avatar
end

Then my Speakers controller will accept an avatar to be uploaded. My speaker_params will now look like:

def speaker_params
    params.permit(:name, :company, :email, :avatar)
end

The file should now look like this:

class SpeakersController < APIController
    before_action :set_speaker, only: %i[show update destroy]    def index
        @speakers = Speaker.all
        render json: @speakers, status: :ok
    end    def create
        @speaker = Speaker.create!(speaker_params)
        render json: @speaker, status: :created
    end    def show
        render json: @speaker, status: :ok
    end    def update
        @speaker.update(speaker_params)
        head :no_content
    end    def destroy
        @speaker.destroy
        head :no_content
    end    private    def speaker_params
        params.permit(:name, :company, :email, **:avatar**, :social_media)
    end    def set_speaker
        @speaker = Speaker.find(params[:id])
    end
end

I have to specify on my request body a field named avatar and its value will be a file, that’s going to be used as the speaker avatar.

After you finish your POST request and you navigate to the storage directory you’ll see a newly created directory containing your uploaded file. If you wish to verify that the file is linked to your speaker you can start rails console and type:

irb(main):001:0> speaker = Speaker.find(1)
=> #<Speaker id: 1, name: “Rafael”, email: “rafael.almeida@xing.com”, company: “XING”, social_media: nil, created_at: “2018–10–02 09:58:54”, updated_at: “2018–10–02 09:58:54”>
irb(main):002:0> app.url_for(speaker.avatar)
=> “http://localhost:3000/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBCZz09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--372a32ffdde03c2f2a37f407e63d10c909fd52ba/xing-photo.jpg"

Et voilá, Active Storage is configured and ready to be used.

Bonus tip

If you execute a GET request on your API you’ll get the information about your speaker that you defined on your migration, like the example below:

{
    "id": 2,
    "name": "Rafael",
    "email": "rafael.almeida@xing.com",
    "company": "XING",
    "social_media": null,
    "created_at": "2018-10-02T09:59:28.494Z",
    "updated_at": "2018-10-02T09:59:28.497Z"
}

However, you also might want to get the associated avatar. We can use a serializer in order to achieve what we intend. You’ll need to add gem 'active_model_serializers' and then include the following line in every controller that you want to get override with the serializer: include ActionController::Serialization. After that you can use rails g serializer speaker and Rails will generate the file for you.

In order to get the associated avatar your serializer should look like:

class SpeakerSerializer < ActiveModel::Serializer
  attributes :id, :name, :email, :company, :avatar

  def avatar
    rails_blob_path(object.avatar, only_path: true) if object.avatar.attached?
  end
end

Now if you re-run your GET request you’ll see something like:

{
    "speaker": {
        "id": 2,
        "name": "Rafael",
        "email": "rafael.almeida@xing.com",
        "company": "XING",
        "avatar": "http://localhost:3000/rails/active_storage/blobs/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBCdz09IiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19–515a0de8817b3529b5d3d168871cebf6ccee0463/xing-photo.jpg"
    }
}

You’re now able to see the avatar associated with every speaker.

HTTP Methods and why you should be using them on your API

Rafael Almeida — Fri, 02 Aug 2019 11:10:54 +0000

Every single one of us has, even if without knowing, used the HTTP protocol before. Otherwise, I wouldn’t have written this on DEV Community and, therefore, you wouldn’t be reading it.

When writing REST API’s one should ensure that it uses the standard HTTP methods. These are a great pillar to build a stable and, very important, scalable API. GET, POST, PUT… which one should I use? My answer to that is: depends on what you want to do!

When should I use each method?

The main HTTP verbs, or methods if you prefer to call them that, are:

GET
POST
PUT / PATCH
DELETE

You may be like:

“Hey thanks, I didn’t know about that! But… when am I supposed to use each one of them?”

Let me explain them to you (and hopefully don’t make this too boring)!

GET

If you check the specification of the HTTP/1.1 protocol it says, and I quote:

“The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.”.

Simplifying this is to say that the GET verb (or method) should be used to retrieve the information you’re looking for. Take the following URL:

https://api-url.dev/api/v1/users/1

It should retrieve all the accessible information about the user with the ID 1.

POST

Let us check the specification of the HTTP/1.1 protocol yet again. It says:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

Annotation of existing resources;

Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;

Providing a block of data, such as the result of submitting a form, to a data-handling process;

Extending a database through an append operation.

Well, these are a lot of words to say that the POST verb to store information on the server.

Take the following URL:

https://api-url.dev/api/v1/users

This should be used to create a new user. You can send all the required information (username, password, etc.) using the body of the HTTP request you’re going to make.

PUT / PATCH

Let us check the HTTP/1.1 protocol one more time. What does it say about PUT verb?

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.

In other words, the text above is telling us that we should use the PUT verb to update an existing resource, say, for instance, an existing user.

Using the URL:

https://api-url.dev/api/v1/users/1

The system should update the information regarding the user with the ID 1 with the information sent in the request.

But… what about the PATCH verb?

Right! The PATCH verb. Say, for instance, that you want to update the user with the ID 1, like the example right above, but you just want to send just the newly updated field, let’s say the password field. In this case, you should use the PATCH verb. Why? Because you’re just sending a fragment of the user entity, which in this example is the password, thus this verb is adequate as you’re PATCHing the given user.

DELETE

Ah, the last but not the least: the DELETE verb. So, checking the specification one last time (finally no?) we get the following:

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

Deciphering the slightly confusing text it says that you should be using the DELETE verb every time that you want to remove some resource from the server.

If you execute a DELETE request on the following:

https://api-url.dev/api/v1/users/1

The server should delete the user with the ID 1 and, perhaps, all the resources associated with him.

And that’s it! I’ve covered up everything I’ve proposed at the beginning of the article. Hope that you enjoyed the reading and let me know if you have any question or suggestion to improve.

Automate Your Slack Interactions

Rafael Almeida — Mon, 29 Jul 2019 11:26:13 +0000

I’m a big fan of automating repetitive tasks and I always try to automate everything I can. Remember the guy that automated part of his job? I try to do some similar stuff too! Imagine the following scenario: every time that you close your MacBook Pro lid it sends a message, telling your team that you’re gone for the day. In this article, I’m going to show how to do this!

To send messages on Slack, you’ll need a Slack Access Token. To get one you need to create a new Slack app, install in your workspace, go to OAuth & Permissions and copy your generated OAuth Access Token.

To be able to execute scripts when your Mac goes to sleep or wakes up we’ll use Bernhard Baehr’s SleepWatcher 2.2. After you download the file, unpack it and open a new Terminal window on its directory and type the following:

$ sudo mkdir -p /usr/local/sbin /usr/local/share/man/man8

$ sudo cp sleepwatcher /usr/local/sbin

$ sudo cp sleepwatcher.8 /usr/local/share/man/man8

In this article, I’m just going to write about the sleep event trigger. If you want to know about more events or read the documentation just type:

$ man sleepwatcher

Now that SleepWatcher is in the correct place you can try the script that’s going to be executed with the following command:

$ /usr/local/sbin/sleepwatcher --verbose --sleep /path/to/your/sleepscript

After you’re finished with the tests and everything behaves as expected is time to setup SleepWatcher to run as a daemon. To do this you can type the following commands:

$ sudo cp config/de.bernhard-baehr.sleepwatcher-20compatibility.plist /Library/LaunchDaemons/de.bernhard-baehr.sleepwatcher.plist
$ sudo cp config/rc.* /usr/local/bin

After that just execute to start your daemon.

$ sudo launchctl load /Library/LaunchDaemons/de.bernhard-baehr.sleepwatcher.plist

Now that everything is ready you need to write the script that’s going to be executed every time your computer goes to sleep. We’re calling it .sleep and make it executable:

$ touch ~/.sleep
$ chmod +x ~/.sleep

In this file, we’re going to place the code that’s going to be used to post our messages to Slack. Mine looks like:

#!/bin/bash

STARTING_TIME="17:00"

ENDING_TIME="19:00"

CURRENT_TIME=$(date +%H:%M)

CURRENT_DATE=$(date "+%d/%m/%Y")

READ_DATE=$(cat ~/.say_message.lock)

if [[ "$CURRENT_TIME" > "$STARTING_TIME" ]] && [[ "$CURRENT_TIME" < "$ENDING_TIME" ]] && [[ "$READ_DATE" < "$CURRENT_DATE" ]]; then

    TOKEN=xoxp-2…

    CHANNEL=#channel_name

    declare -a EXPRESSIONS=("Write" "Your" "Expressions" "Here")

    SELECTED_EXPRESSION=${EXPRESSIONS[$RANDOM % ${#EXPRESSIONS[@]} ]}

    curl -X POST \

        --connect-timeout 10 \

        --max-time 10 \

        --retry 10 \

        --retry-delay 0 \

        --retry-max-time 60 \

        --'content-type: multipart/form-data' \

        -F token=$TOKEN \

        -F "channel=$CHANNEL" \

        -F text="$SELECTED_EXPRESSION" \

        -F as_user=true \

        https://slack.com/api/chat.postMessage

        echo $CURRENT_DATE > ~/.say_message.lock

fi

Let me explain the script line by line.

Script explanation

I’m using the following variables to specify that the message is meant to be sent only between 17:00 and 19:00

STARTING_TIME="17:00"

ENDING_TIME="19:00"

These are used to ensure that the message is only sent once per day, to prevent sending it every time that you lock your computer, for instance.

CURRENT_TIME=$(date +%H:%M)

CURRENT_DATE=$(date "+%d/%m/%Y")

READ_DATE=$(cat ~/.say_message.lock)

The if condition bellow allows me to ensure that the conditions I’ve specified above are met. Which are: the message is only sent between 17:00 and 19:00 and only executes once per day.

if [[ "$CURRENT_TIME" > "$STARTING_TIME" ]] && [[ "$CURRENT_TIME" < "$ENDING_TIME" ]] && [[ "$READ_DATE" < "$CURRENT_DATE" ]]; then

fi

To send the message to the desired channel you have to specify the token you got from Slack and the channel to post the message. I also have an array of expressions to be randomized later. This is meant to send a different message. To achieve this I have the following lines:

TOKEN=xoxp-2[…]

CHANNEL=#channel_name

declare -a EXPRESSIONS=("Write" "Your" "Expressions" "Here")

SELECTED_EXPRESSION=${EXPRESSIONS[$RANDOM % ${#EXPRESSIONS[@]} ]}

When everything is set we need to send our message to Slack API. This is done using cURL. These are my configs:

curl -X POST \

--connect-timeout 10 \

--max-time 10 \

--retry 10 \

--retry-delay 0 \

--retry-max-time 60 \

--'content-type: multipart/form-data' \

-F token=$TOKEN \

-F "channel=$CHANNEL" \

-F text="$SELECTED_EXPRESSION" \

-F as_user=true \

https://slack.com/api/chat.postMessage

I’m telling cURL to:

Each attempt last 10 seconds with --max-time 10
Retry 10 times using --retry 10
Disable cURL sleep between retries using --retry-delay 0
Wait 60 seconds max using --retry-max-time 60

The code above will send a POST request to https://slack.com/api/chat.postMessage with the specified payload. You can check more about postMessage endpoint reading Slack documentation.

After the execution of the request I’m updating the “lock” file with the new date with the line:

echo $CURRENT_DATE > ~/.say_message.lock

This is meant to ensure that only one message per day is sent.

This is how I automated my interactions with Slack. Let me know your thoughts on this using the comments below.

Enhancing your git commit messages

Rafael Almeida — Thu, 25 Jul 2019 09:56:41 +0000

If you're reading this chances are that you're already aware of what git is and you also work with any ticket-based software, like Jira. In this article, I'm going to show you how automatically prepend the ticket ID you're working on to your commit message, assuming that you're using you're branch names similar to feature/ABC-1234-Feature-testing.
To achieve this, you're going to use git hooks.

Git hooks

According to Git Hooks:

Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. Git hooks are a built-in feature - no need to download anything. Git hooks are run locally.

Now that you know what you need, just create a new file under .git/hooks folder. Name it prepare-commit-msg.
Copy the code below and paste it into your newly created file.

#!/bin/bash

# List the branches that don't apply bellow
if [ -z "$BRANCHES_TO_IGNORE" ]; then
  BRANCHES_TO_IGNORE=(master develop staging test)
fi

# Pick the current branch name and check if it is excluded
BRANCH_NAME=$(git symbolic-ref --short HEAD)
BRANCH_IGNORED=$(printf "%s\n" "${BRANCHES_TO_IGNORE[@]}" | grep -c "^$BRANCH_NAME$")

# Remove the unnecessary parts
TRIMMED=$(echo $BRANCH_NAME | sed -E -e 's:^(\w+)\/([^-]*-[^-]*)-.*:\2:' -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/')

# If it isn't excluded, prepend the part that interests us to the given commit message
if [ -n "$BRANCH_NAME" ] &&  ! [[ $BRANCH_IGNORED -eq 1 ]]; then
  sed -i.bak -e "1s/^/$TRIMMED - /" $1
fi

After the creation of the file, you'll need to give it its proper permissions. This can be achieved by executing chmod +x prepare-commit-msg.
If you want to see it in action just make a new commit and type any message you want. You should see now, given the branch name above, something like:

commit 976f4354779a824e5edfd851857b26c9bcfd3e14 (feature/ABC-1234-Feature-testing)
Author: Rafael <email@example.com>
Date:   Tue Jul 23 17:35:25 2019 +0100

    ABC-1234 - This is a testing message

Apply your changes globally

Now that I've shown you how to improve your commit messages you'll want to apply the condition to every other repo in your machine, right? I'm going to show you how to achieve it.
The first step is to create a folder that's going to contain all of your hooks. I'm using this repo I've created but you can use whichever you prefer. After having your own folder you execute the following command:

git config --global init.templatedir '~/projects/git-hooks-templates'

Within you should have another folder named hooks, this is where we're going to place our git hooks.
Now that the folder structure is correct you can copy the file created above into the, in this example (yours might differ) ~/projects/git-hooks-templates directory. The command to execute after is:

chmod a+x ~/projects/git-hooks-templates/hooks/prepare-commit-msg

Now you have everything set up. Every time that you create or clone new repositories your commit messages will be appended with the ticket ID based on the branch that you're working on.