[RAILS] What is Jenkins? ] Installation-how to use-automatic test / automatic deployment will be explained in the world's easiest way

(The shell you are using is "/bin/zsh ")
Hello, Yamamoto Ryûken Mr.

Is displayed, it is successful.

You have now created a job that runs a script that you have placed in your workspace.

You can end this chapter here, but to get used to the shell script, let's modify the Jenkins shell script to create variables and then pass them to script.sh.

Open the settings from the job and do the following:

Before correction

sh script.sh Ryuken Yamamoto

Revised

FIRSTNAME=Yamamoto
LASTNAME=Ryuken
sh script.sh $LASTNAME $FIRSTNAME

※Caution

FIRSTNAME=Yamamoto
LASTNAME=Ryuken
sh script.sh $LASTNAME $FIRSTNAME

,

FIRSTNAME=Yamamoto
LASTNAME=Ryuken
sh script.sh $LASTNAME $FIRSTNAME

If you put a space after and =, the job build will fail.

Click Save to run the build and open the latest build history to see the console output.

The result is similar.

Take advantage of Jenkins build parameterization

I've ignored it a lot, but for the first time I'd like to use one of the options, "build parameterization".

Now, in the shell script, the FIRSTNAME and LASTNAME variables are prepared, and the values are set and used.

Parameterize these to build. Check Build Parameterization.

Then select a string from Add Parameter.

Then, a field for entering the name, default value, and description appeared.

Enter FIRSTNAME for the name, Yamamoto for the default value, and surname for the description.

You have now parameterized one variable to your build. Next, create another one.

Select the string from Add Parameter again.

Enter LASTNAME for the name, Ryuken for the default value, and name for the description.

You have now parameterized the two variables in your build.

Finally, remove the unnecessary description from the Jenkins shell script and rewrite it as follows.

Before correction

FIRSTNAME=Yamamoto
LASTNAME=Ryuken
sh script.sh $LASTNAME $FIRSTNAME

Revised

sh script.sh $LASTNAME $FIRSTNAME

Now the shell script is refreshing. This alone feels like a benefit, but it's not the only benefit. Here are the benefits of real build parameterization. Click Save.

At this point, you will notice that one display has changed. The part that was previously a build execution has changed to a build with parameters.

Let's click it right away.

The build execution started immediately when I clicked on the build execution, but by setting the build parameterization, it is now possible to change the value of the variable before the build execution.

Click Build as is once, and when finished, open the console output from the latest build history.

The displayed string is the same as in the previous chapter. Then go back to the project → Build with parameters. This time, I will make my last name and also my first name.

Click Build and when you're done open the console output from the latest build history.

You can see that the displayed name has changed. By setting build parameterization, you can now change variables each time you run a build. You can also set default values, which is a useful feature if you need to change variables each time you run a build.

The usage of build parameters is endless. In this chapter, it's okay if you can tell that build parameterization can be used in various ways.

Make Jenkins build parameterization selective

Build parameterization can be selectable as well as string input. All the parameterization of the build is done once.

Then choose to select additional parameters.

Make settings to make the surname and first name selectable according to the image below. The surname can be selected from "Yamamoto", "Katsumata", and "Bannai". You will be able to create a name in the same way and select from "Ryuken", "Kenta", and "Manabu".

Click Save, then click Build with Parameters.

I was able to confirm that the surname and first name are selectable. Change the surname to "Bannai" and the name to "Manabu".

cool. (Imitation of a foreign teacher)

Then click Build and then click Console Output from Latest Build History.

It was confirmed that the selected names "Bannai" and "Manabu" are displayed. As an aside, Manab is the same age as me and is four months apart.

You have now made the build parameterization selective.

Show / hide using Jenkins build parameterization

I used to show which shell I was using, but since I don't need to show it every time, I will use build parameterization to show / hide it.

From the job settings, select a boolean value in Add Parameter.

The name is SHOWSHELL, the default is unchecked because I want to hide it, and the description can be checked to show the shell you are using. will do.

Click Save.

Next, rewrite the script.sh placed in the workspace so that the shell is displayed if SHOWSHELL is true (1) and the shell is not displayed if SHOWSHELL is false (0).

Before correction

/Users/username/.jenkins/workspace/Job that outputs characters in the shell/script.sh

#Outputs the type of shell you are using
echo "(The shell you are using is "$SHELL ")"

#Show name
LASTNAME=$1 #Pass the name as the first argument
FIRSTNAME=$2 #Pass the surname as the second argument
NAME=$FIRSTNAME$LASTNAME #Attach the surname and first name
echo "Hello,$NAME"

Revised

/Users/username/.jenkins/workspace/Job that outputs characters in the shell/script.sh

#Variable definition
LASTNAME=$1 #Pass the name as the first argument
FIRSTNAME=$2 #Pass the surname as the second argument
SHOWSHELL=$3 #Pass a flag to the third argument whether to print the shell

#Outputs the type of shell you are using
if [ "$SHOWSHELL" = "true" ]; then
	echo "(The shell you are using is "$SHELL ")"
fi

#Show name
NAME=$FIRSTNAME$LASTNAME #Attach the surname and first name
echo "Hello,$NAME"

Go back to working with Jenkins and click Build with Parameters.

This time, the shell I'm using is no longer displayed, so just click Build to display the console output from the latest build history.

It was confirmed that the shell type that was displayed until now is no longer displayed.

You can now show or hide it using build parameterization.

Automatically test your rails application with Jenkins

Bring your rails application from GitHub and create a job for testing and static analysis in Jenkins.

How to create rails application, how to install Homebrew which is software to install rbenv and its rbenv which can easily rewrite ruby version, rspec used in automatic test, rubycop used as static analysis tool I will omit the introduction method. There are personal apps with rspec and rubocop installed on GitHub below, so I will explain using this as an example. https://github.com/EL93019205/stuctive.git rails uses 5.2.3 and ruby uses 2.5.1.

There is an article that introduces the procedure for installing the plugin, but no plugin is required except the default one. ~~ The plugin is generally old and not very useful ~~

Now let's create a new job.

Job name is rails It must be in English for the convenience of. This time, set it to "stuctive_auto_test".

The job type should be Freestyle Project Build.

Click OK when you are done.

Since there is an item called source code control, I will use Git. Then, the following screen will be displayed.

GitHub in the repository URL Now, what should I enter in the repository URL? The answer is on GitHub.

Click the green button Code from the URL below (the URL to the repository of my personal app), and click the icon to the right of the part where the URL is written. This icon represents a copy. Since it is a public repository, I think anyone can copy and use it. https://github.com/EL93019205/stuctive

Then paste "https://github.com/EL93019205/stuctive.git" into the repository URL as shown below.

This is the only source code control setting. You don't have to play with anything else.

Did you think, "What? That's it?" Yes, that's it.

If you have secure settings, you may need to set credentials, and if the branch to be automated tested is other than master, you may need to change the branch to build, but my personal app is in the public repository. And since the branch you want to do automated testing is master, you don't have to mess with it.

This setting clones the rails application to your workspace.

Click Save Once.

Open the workspace.

You can see that the workspace does not exist.

As I wrote above, the workspace will not be created unless the build is executed once. So click Run Build.

You can see that the build history has turned blue.

Open the workspace again.

It is as follows. If you've ever written a rails application, you're probably familiar with all the files.

This data is exactly the same as the data on GitHub below. https://github.com/EL93019205/stuctive

In this way, it's super easy to copy a set of rails application data on GitHub to your Jenkins workspace.

All that remains is to execute the automated test command with this retrieved data in the directory containing the Gemfile. The command of the automatic test is completely different depending on the version of rails, but since we are using rails 5.2.3 this time, it can be executed with the following command.

bundle exec rspec
bundle exec rubocop

Let's do this.

Open the settings.

Scroll to the bottom and paste the command above into running the shell. This command runs in the workspace directory. In other words, it will be executed in the directory where the Gemfile is located. Click Save when you are done.

Then run the build.

Ah, the build history turned red. What was the cause?

Click ● </ font> # 2 to open the console output.

printenv | grep PATH

export PATH="Paste the contents of the PATH you copied earlier"
bundle exec rspec
bundle exec rubocop