Introduction

Let’s have an idea to create a separate database for integration testing. Creating a separate database will require creating a Docker file with a PostgreSQL database. We can consequently make and run dedicated integration CI/CD workflow for the integration tests. This CI/CD workflow will take our Docker PostgreSQL database and run the database with which integration tests will be working.

Creating Dockerfile

We will need to write three files for creating a database testing environment. Technically, we need to write only one file – Dockerfile. But two other files, database init scripts, will be used to prepare our containerized database for integration tests.

First we need to write PostgreSQL Dockerfile:

FROM postgres:latest
ENV POSTGRES_USER postgres
ENV POSTGRES_PASSWORD admin
ENV POSTGRES_DB postgres
COPY ./sql/db_user_creation.sql /docker-entrypoint-initdb.d/
COPY ./sql/init_tables.sql /docker-entrypoint-initdb.d/

Let’s take latest image of PostgreSQL database from posgres Docker vendor. We set up PostgreSQL’s image environment properties POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB by default values and copy our database init scripts to Docker image entry folder.

The official postgres docker image will run .sql scripts found in the /docker-entrypoint-initdb.d/ folder. I highly encourage you to check official documentation in case in future postgres releases might change this.

Best practice

I will go here a little bit sideways. There is a good practice to add on custom-defined Dockerfile last Docker commands from a source image.

ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 5432
CMD ["postgres"]

The last three lines of our Dockerfile are copied from the Postgres image and considered a best practice. However, you can omit them. But in case you want to extend this Dockerfile further, please realize that first, you are running all commands in the Postgres source image. And only then you are running your custom Docker commands. Placing the last command from PostgreSQL’s image will secure consistent API.

Therefore, the Whole Dockerfile should look like this:

FROM postgres:latest
ENV POSTGRES_USER postgres
ENV POSTGRES_PASSWORD admin
ENV POSTGRES_DB postgres
COPY ./sql/db_user_creation.sql /docker-entrypoint-initdb.d/
COPY ./sql/init_tables.sql /docker-entrypoint-initdb.d/
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 5432
CMD ["postgres"]

The environment variables will instruct the container to create a postgres schema with postgres user (having admin password) on its first run. Any .sql files found in the /docker-entrypoint-initdb.d/ of the PostgreSQL container will be executed. If you want to execute .sh scripts, you can also place them in the /docker-entrypoint-initdb.d/ folder.

Custom init scripts

As you have noticed in Dockerfile description, we have created two other files which we copied to PostgreSQL image. First file is db_user_creation.sql:

CREATE USER mycustomsuperadmin WITH PASSWORD 'changethispassword';
GRANT ALL PRIVILEGES ON DATABASE postgres TO mycustomsuperadmin;

In this file, we could, for example, add a command for creating another database. However, only for demonstration purpose, we will create mycustomsuperadmin user with all the privileges for postgres database. Creating a new user is not mandatory.

The second file we need to create is the initialization of our database with tables and content. This file is also just for demonstration purposes, and you can come with your ideas and needs for what you need to put into the database. Here is example of some database tables we will pad into postgres database.

CREATE TABLE "public".items (
    "id"           integer NOT NULL GENERATED ALWAYS AS IDENTITY (start 1),
    name           varchar(50) NOT NULL,
    price          double precision NOT NULL,
    release        timestamptz(3) NOT NULL,
    CONSTRAINT     PK_Customer PRIMARY KEY ("id", "name", "price", "release")
);

CREATE TABLE "public".users (
    "id"           integer NOT NULL GENERATED ALWAYS AS IDENTITY (start 1),
    name           varchar(50) NOT NULL,
    salary         double precision
    timestamp      timestamptz(3) NOT NULL,
    CONSTRAINT     PK_Customer PRIMARY KEY ("id", "name", "salary", "timestamp")
);

Again, the following code is just for demonstration purposes, and naturally, you can place your own init scripts here.

Note : Default syntax for creating database in PostgreSQL is “database_name”.”scheme_name”.”table_name”.

Build Dockerfile

Now, when we have all the files, we need to run the Docker build command. So, go to the folder where you placed PostgreSQL Dockerfile and run Docker build command like this:

IntelliJ configuration

You can easily build and run your Docker image from IntelliJ. Check the image of configuration for setting up the file:

Docker build .

Hitting the following setup in IntelliJ will build your Dockerfile and place it in your local Docker repository.

Alternative with docker-compose

There is alternative way how to build and run PostgreSQL locally. It is without creating Docker image and instead just run docker-compose. Here is a code for docker-compose.yaml file:

version: '3.7'
services:
    postgres:
        image: postgres:latest
        restart: always
        environment:
            POSTGRES_USER: postgres
            POSTGRES_PASSWORD: admin
            POSTGRES_DB: postgres
        logging:
            options:
                max-size: 10m
                max-file: "3"
        ports:
            - '5432:5432'
        volumes:
            - ./postgres-data:/var/lib/postgresql/data
            # copy the sql script to create tables
            - .sql/init_tables.sql:/docker-entrypoint-initdb.d/init_tables.sql
            # copy the sql script to create user
            - .sql/db_user_creation.sql:/docker-entrypoint-initdb.d/db_user_creation.sql

Running docker-compose up -d will run docker-compose script in your repository. To turn off the service, execute command docker-compose down.

Node: So if you placed your Dockerfile in project-root/src/test/resources and you are in your command prompt on this sys-path, running docker-compose might first run docker-compose in your project-root/ folder.

Conclusion

This article has shown us how to create a PostgreSQL database Dockerfile. However, we can develop this idea further and, for example, make it for integration tests in a separate CI/CD workflow.

Did you find creating Dockerfile easy? Do you have your trick or know another way how to create Dockerfile? Let us know in the comments below the article. We would like to hear your ideas and stories.

• Introduction
• Change Future Commits Author
• Git Config Check
• Git Global Configuration
• Git Local Configuration
• Author Identity For the Next Commit
• Change Past Commits Author
• Git Ammend With Author Flag
• Git Interactive Rebase
• Git filter-branch Command
• Conclusion

Introduction

There are two different needs in the request of changing author for your commits. Let’s make clear what are you really looking for:

• a) Either you want to change the author before making commit.
• b) Or you want to change the author after you have made commit.

In this article, we will look at both ways how to change the commit’s author identity.

Change Future Commits Author

There are three different ways how to change identity for your Git committer. All the procedures only affect future commits and not the past commits made in the development line of your repository (commit history).

Git Config Check

Just a quick tip. To confirm your settings for global and local configuration you can type command:

git config --list

git config --list will show global system git settings. If you run it inside a repository, it will also attach and show you the local configuration.

However, using following command might be more clearer:

git config --list --show-origin

git config --list --show-origin command does all what git config --list does. Git command also attaches a path to the origin file of each config item in the list. Arguably, the attached path makes the settings look more understandable, and you can better connect items and their values for local and global Git settings.

Git Global Configuration

If you want to change your username and email by default for all project on your machine, edit global configuration settings. You can run the git config command with --global flag that will override your default Git settings and apply for all the future commits in your repositories. Git command for it looks like this:

git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL@example.com"

Git Local Configuration

However, if you want to change your username and email only for single project, go to your repository and make git config adjustment like this:

git config --local user.name "FIRST_NAME LAST_NAME"
git config --local user.email "EMAIL@example.com"

Simply omit the --global flag and replace it with --local flag. git config --local makes the custom configuration valid only in the repository you made a change.

Author Identity For the Next Commit

There is at least one last way how to temporary influence the author identity of the commit. Just right before making the commit, add to commit command --author flag. When making the commit, you can override even local settings.

git commit --author="FIRST_NAME LAST_NAME "

Change Past Commits Author

Changing past commit authors in Git repositories is not so straightforward as it is for future ones. The issue lies in the fundamental idea of Git – its distributed asynchronous nature. You should be aware of one simple fact that you might cause a massive problem with synchronization if you work on the project with many team members.

When you change Git commit author identity, you create an entirely new commit with a new hash; you are rewriting commit history and development branch. And while for a single individual repository user, this might not be a problem, for big teams, this might be a cause of enormous evil.

Therefore, let me give you a piece of good advice: if you are working in a team, a change in Git commit history should be adequately communicated with the rest of the team. It might happen that other team members already based their work on the existing commits, and additional changes would cause huge synchronization problems. Communicate with your team if you feel that commits might be already used as the base for other people work. Eventually, for good or bad, it might be possible even to avoid changing commit author identity, and either do rollback commit with new commit with correct author commit or, better, leave the commit history as it is. Commit change is much more critical in the long term as a person who made it (empirical experience – people come and go from teams, code stays forever).

Git Ammend With Author Flag

git ammend command is used to patch last commit in Git’s commit history. By attaching --author flag to git ammend command you can effectively rewrite commit author identity for the last commit in commit history.

Git Interactive Rebase

Interactive rebase is a powerful feature of Git that allows you to edit Git commit history very effectively.

However, be careful with interactive rebase, it might shoot you in the foot if you will be not careful! Any changes made will affect your Git commit history. I would recommend to study deeper official Git documentation for interactive rebase before making any changes with it over console [7.6 Git Tools – Rewriting History]. Otherwise I can really recommend using interactive rebase with IDE tools such as IntelliJ.

First step, you need to find commit you consider as base for your interactive rebase. Provide to git command commit’s hash like this:

$ git rebase -i -p 9be2477a

git rebase command will open the interactive editor in which you need to mark all the commits you want to change. Selected commits will be marked with the red keyword “edit”.

edit 87bee32a Added new tests
edit 1be09dcb Merge branch with hotfix for DJ-1041
edit 9be2477a Change title tag for homepage
edit c427697c Add images support in gallery

Git will now walk you through each commit. You will have a chance to change every commit individually:

Stopped at 1be09dcb... Merge branch with hotfix for DJ-1041
You can amend the commit now, with

    git commit --amend

Once you are satisfied with your changes, run

    git rebase --continue

Now is your chance to rewrite the commit author identity. Either you will use --amend with --author flag. Or you will continue to next commit in edit mode until you have edited all commits which were marked for edit

$ git commit --amend --author="FIRST_NAME LAST_NAME " --no-edit
$ git rebase --continue

Git filter-branch

Last option is to use Git filter-branch command. filter-branch will allow you to go through a large chunk of commits with the help of simple script. Let us show you a simple script:

$ git filter-branch --env-filter '
OLD_COMMITTER_EMAIL="OLD_EMAIL@example.com"
NEW_COMMITTER_NAME="FIRST_NAME LAST_NAME"
NEW_COMMITTER_EMAIL="NEW_EMAIL@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_COMMITTER_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$NEW_COMMITTER_NAME"
    export GIT_COMMITTER_EMAIL="$NEW_COMMITTER_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_COMMITTER_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$NEW_COMMITTER_NAME"
    export GIT_AUTHOR_EMAIL="$NEW_COMMITTER_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

However, same as with interactive rebase, it is necessary to be aware that by using filter-branch, you will create entirely new sort of commits and change Git commit history. The new commit history might have severe consequences when synchronizing with your team, so you should do this preferably only on repositories that haven’t been published or shared.

Conclusion

In summary, we divided the methods of changing the commit author identity into two different approaches based on the commit stage. We showed three different ways to change the author information before making a commit, and we explained another three ways to change the author information after making a commit.

Did you find commands easy? Do you have your trick or know another way how to change global and local Git settings? Let us know in the comments below the article. We would like to hear your ideas and stories.

How to set hot swap with Trava Open JDK in your IntelliJ Idea

1. Install to your computer Trava Open JDK. You can find installation binaries at Trava Open JDK on GitHub. If you are Windows user, I would give you a tip to just download Windows binaries and unpack them to folder where you have the rest of JDKs. Exp. C:/Program files/Java/ .
2. In IntelliJ Idea go to Project Structure and under Platform Settings add to SDKs Trava Open JDK. Also under Project Settings in Project SDK select Trave Open JDK as JDK for your project.
3. And as last step change in IntelliJ Spring Boot runner configuration Running Application Update Policies. Change On ‘Update’ action and set it to Update classes and resources and On frame deactivation set the same to Update classes and resources. You can check image below for more details.

And that is all. You can start your app now, and your code will be hot-swapped on frame deactivation. Or you can command hot-swap manually with ctrl + shift + f9.