Understanding .ci/* files

[ThatSneakyCoder]

The .ci/ folder is an interesting one to me.
I have some questions related to this directory .ci/.

Question 1

What's the purpose of writing all these shell files. (Is it for automation?! For the CICD on github?!)

Question 2

2.1

How are these shell files communicating with each other. I want to draw out (in the sense diagramatically visualize) as to which file is communicating with what file.

2.2

Is validation.sh the main file here. In the sense only until validation.sh is triggered that the rest of the files will be triggered.

2.3

What triggers validation.sh and why?

Question 3

If I were to ask you to remove all these shell files completely, that is totally remove .ci/* files then what is the next best possible way to achieve the same thing that these shell files are meant to achieve.

Question 4

Is there any job that these files fail to achieve as of now? What are they? What are potential fixes for them?

(Please share documentation link if possible for anything that seems viable to share for this)

[rnveach]

What's the purpose of writing all these shell files. (Is it for automation?! For the CICD on github?!)

All these shell scripts are to do some type of verification of Checkstyle. They can be internal, checking CS against another project, or running an external tool against CS.

We have found it is better to not have a single massive file, but split it apart into groupings. So no-exception contains all of the no exception testing of CS on external projects and codes, pitest runs the tool pitest against CS and it's tests, etc...

How are these shell files communicating with each other. I want to draw out (in the sense diagramatically visualize) as to which file is communicating with what file.

I am not aware of any scripts communicating with others, except for some rare occurrences. Most scripts are self-contained as that makes them easier to manage and debug. Most are a few simple commands executed to produce a good/bad result.

util.sh is a library for common functions. pitest shell does call pitest groovy but only to make working with the pitest library easier.

I am not familar with all these scripts individually, and things are always changing.

Is validation.sh the main file here. In the sense only until validation.sh is triggered that the rest of the files will be triggered.

In a way. It is a more important script but it was named such as a "miscellanous" file. We have too many scripts to give them all unique names like pitest and no-exception. It was not named such to be the boss to all the other scripts. There is no boss script, just ranges of usefulness in the issues they look for. The YML files are more the bosses for their specific CI.

What triggers validation.sh and why?

While you can trigger the scripts locally for your own reasons, our CI triggers the scripts and this is why the folder is named "CI". You should be able to look at our YML related CI files and see calls to the different scripts in them.

If I were to ask you to remove all these shell files completely, that is totally remove .ci/* files then what is the next best possible way to achieve the same thing that these shell files are meant to achieve.

Your basically asking us to remove something important to validate the changes PRs are making to the code. Obviously, we would find whatever way we could to do this without shell scripts.

We have been using groovy as an alternative to be more OS friendly, but we have really only been using it for complex scripts. I personally am not a fan of script languages because of the lack of IDE support as can be obtained with languages like Java. Majority of administrators are on Linux, hence why majority of our scripts are shell scripts. As a Windows user, I am forced to set up a VM to run shells for this project.

Is there any job that these files fail to achieve as of now? What are they? What are potential fixes for them?

They fail to replace a human reviewer....

Any issues we have with the scripts are logged in an issue somewhere. Obviously the biggest failure would just being OS friendly, but I don't see it as that big an issue.

[ThatSneakyCoder]

I am not aware of any scripts communicating with others, except for some rare occurrences. Most scripts are self-contained as that makes them easier to manage and debug. Most are a few simple commands executed to produce a good/bad result.

okay.

[ThatSneakyCoder]

Is validation.sh the main file here. In the sense only until validation.sh is triggered that the rest of the files will be triggered.

In a way. It is a more important script but it was named such as a "miscellanous" file. We have too many scripts to give them all unique names like pitest and no-exception. It was not named such to be the boss to all the other scripts. There is no boss script, just ranges of usefulness in the issues they look for. The YML files are more the bosses for their specific CI.

Okay so basically these shell scripts have been written according to convenience. Not that validation.sh has to be necessarily triggered in order for the rest of the .sh files to be invoked. In short even other shell files apart from validation.sh can trigger other shell files.

The YML files are more the bosses for their specific CI.

Okay I am going to study these yaml files in detail then. I want to know how they control these shell files.

[ThatSneakyCoder]

What triggers validation.sh and why?

While you can trigger the scripts locally for your own reasons, our CI triggers the scripts and this is why the folder is named "CI". You should be able to look at our YML related CI files and see calls to the different scripts in them.

Okay. I will go through the YAML files.

So, in a way these YAML files seems to be invoking these shell script?

[ThatSneakyCoder]

Is there any job that these files fail to achieve as of now? What are they? What are potential fixes for them?

They fail to replace a human reviewer....

Any issues we have with the scripts are logged in an issue somewhere. Obviously the biggest failure would just being OS friendly, but I don't see it as that big an issue.

okay.

[nrmancuso]

@shubh220922 the best way to learn about CI is to set it up for yourself; all CI basically follow the same pattern (config in yml format, workflow runs jobs, jobs run steps), but the yml files themselves have a vendor specific (example: CircleCI) format. I suggest you do the following:

1. Create some simple Java project using maven, can be as simple as a “Hello world” type of program
2. Add a few tests
3. Setup a repo in GitHub for it, push to repo
4. Setup CircleCI for this repo
5. Create simple workflow that runs some maven command like mvn assemble
6. Create a few more jobs in your workflow to do things like run tests, etc

I find CircleCI to be the easiest to deal with, and have the best documentation. Also, it is free for personal use and open source projects :) Once you learn the pattern of CircleCI, you will see that all other CI follow roughly the same pattern.