In a previous article, we were just getting started on automation server by installing and configuring a Jenkins automation server node onto a windows machine (Linux and Mac instructions added as well). What we’re trying to achieve is that to add an automation script which fetches a particular project from a repository (in this case git) and execute build command on the fetched code base. Once completed, we shall look at whether the build was a success or a failure. And we shall see how we can automate a build on every check-in that occurs on the repository configured by anyone. Plus, we shall see how we can configure the build status to be mailed to pre-configured mail addresses in the system along with the build log.
Read: Installing and Configuring Jenkins Automation Server in a Windows [/Linux/Mac] System
In this journey, let’s begin by setting up a git repository for our ReadersAPI which has been all along an uncommitted code. The real-world scenario goes like this: teams of varying sizes and domains collaborate together onto building an application which can contain several layers of architecture and code. And each team saves the code onto a common codebase available for all contributors under a repository (such as git, bitbucket and such) which can handle versioning and merging for the teams.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Once the code is committed on to this repository, each team would be interested in building and testing each time a new set of changes are added on to the base. This is where the automation servers come into play : they just automate a certain recipe (such as build / test / deploy) and iterate over a certain trigger (such as a commit). And repositories do play a major role in handling codebase for collaboration and integrate with automation in these cases.
Getting back to our example, We shall begin by setting up a remote git branch for the project we’re building. Assuming that we have git already installed (if not you can install the git tool for free from the git homepage). In the ReadersApi project directory, I initialize a git repository using the below command:
> git init
This shall initialize a new git repository within the application which is also the starting point to commit a project into git.
Next, we shall add a remote repository endpoint onto which the files shall be committed into. We can get it by clicking on the clone option under our repository in github. Once the url is fetched, we use the below command to configure a remote origin onto which the local git commits shall be written.
> git remote add -m master origin https://github.com/MY_REPOSITORY_GIT.git
Once this is done, we shall add all our files onto the local git for marking to commit. Before this, we create a new file called .gitignore which is a file used by the git to mark unwanted folders or files to not to be committed to the repository. This generally goes for intermediate files or folders such as bin and obj.
# .gitignore file
/bin
/obj
/Any_Folder_Unwanted_For_Commit
/Any_Folder/Any_Sub_Folder_Unwanted_For_Commit
Once this is created, we mark all the files under the current directory to be added to local git registry by below command.
> git add .
This pretty much adds all the files under the current path, except the files which are mentioned under the .gitignore file.
Next, we shall commit the added files with a message to be shown under the branch commits in git. This is mandatory and is useful particularly when collaborating with multiple teams, which work under a shared code base. The message is added under double quotes (important) and shall not exceed 250 characters or so (a best practice).
> git commit -m "My Initial Commit"
Once this is done, we push all the changes to our remote origin under the specified branch by the below command. This will prompt a login window and on typing in the github credentials, this shall commit all the locally marked files to add into the repository.
> git push -u origin master
Which shall write all the local changes onto the server.
Tips:
Sometimes you might face the below error while pushing the local code to remote origin.
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/.../xxx.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
This simply occurs because the local branch version is behind the remote version, to solve this we can do a pull to fetch the latest version from remote. This we can force fetch the latest from remote by using the below command:
> git pull --force origin master
This can result in another error, like below
From https://github.com/xxxx/xxxx
* branch master -> FETCH_HEAD
fatal: refusing to merge unrelated histories
This can be solved by adding another flag while pulling the remote branch
> git pull --allow-unrelated-histories
This solves the pull issue and all the unavailable files shall get into the local git repo. Now we shall push our local commits to the server by using the above push command.
ReadersApi> git push origin master
Enumerating objects: 46, done.
Counting objects: 100% (46/46), done.
Delta compression using up to 4 threads
Compressing objects: 100% (41/41), done.
Writing objects: 100% (45/45), 13.81 KiB | 1.25 MiB/s, done.
Total 45 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/xxxxx/xxxx.git
f01799a..a4c0784 master -> master
This way we can setup and push our local aspnetcore project (if not any codebase for that sake) into a remote git repository.
Now that this is done, we shall next use this git repository to be configured in our jenkins server to automate the fetch -> clean -> build process we desire to achieve. We shall look at it in the next article.
Found this article helpful? Please consider supporting!
