CODEWITHSUNDEEP
gitcontinuous-integrationgitlabgit-bashcontinuous-deployment
Roberto Navarro
Roberto Navarro

Reputation: 958

Auto-append to bash script after GitLab Checkin

Community, without going through the process of setting up GitLab CI (Continuous Integration), do any of you know how I may automate a process as described below?

  1. After GitLab check-in, have the checked-in filename added to either a text file or update a bash-script that references the full path of the file that was checked in?

  2. The bash script would then be used to execute the code in each of the checked-in files.

Bit of background, the files are SQL DDL files needed to build tables/views/packages. I want my DEV team to only worry about updating the DDL, and have a process that automatically builds database objects.

The idea here is to have a bash/perl/ksh whatever file, that calls SQLPLUS and sequentially executes the DDL in each of the files.

To be clear, I already know how to write the BASH code that calls SQLPLUS and iterates over the list of files.. just need a way to automate the filename append, whenever a check-in happens to GitLab.

Welcoming any ideas...

Upvotes: 1

Views: 99

Answers (1)

nwinkler
nwinkler

Reputation: 54457

Here are two ways of doing this.

Git Hooks

This is possible using Git Hooks. A Git Hook is a function that is executed when certain events occur in the repository. They are either server-side or client-side.

Server-side hooks would execute on GitLab in your case, when someone pushes to the repository, while client-side hooks are executed on the client, e.g. before or after a commit.

In your case, the server-side post-receive hook would probably work. Check out one of the tutorials on Git Hooks for more details, e.g. here. You would basically write your script (as you indicated in your question) and then set it up as a post-receive hook on the server to execute whenever there are changes in the repo.

Continuous Integration

While Git Hooks might work for this case, this really sounds like a use case for a continuous integration tool like Jenkins, Travis CI or Bamboo.

These tools are used to trigger a build after changes in a repository. A build usually contains things like compiling sources, running unit tests, deploying an application to a server, creating a distributable version of the application, etc.

In your case, you would set up a build plan that does what you describe in your question (pulling in the changes, updating the text file, running the database scripts, ...).

Based on my experience, I suggest you look into a continuous integration system. This is the standard way of doing things like you're asking, and you will find that there's other things you want to do when someone commits. Having a standardized process like CI in place will help a lot.

Git Hooks might work for this, but are harder to maintain and less flexible.

Upvotes: 1

Related Questions