Jump Ci (jci) is a fun little script that documents in your git repo where all the ci jobs are.
For example, lets say you are in docker/container/myapp and you want to find the
ci job that builds that docker image and pushes it into prod. You would just
run jci and like magic the ci pipeline opens in your browser.
Of course magic doesn't exist, so how does jci know how to get to the correct
CI job? Because someone had already changed to the docker/container/myapp dir
and ran jci add and added the url to the ci.
jci allows you to add this metadata to both directories (so anything in the
directory is tagged to that ci job) or to individual files (so you can call
it with jci <filename>) If the jci will walk backwards until it finds
a match, which also means if you have a directory like myapps and have a
bunch of subdirs in myapps, you can just define one job in the root myapps
directory and all the children will pop back and get that unless they
have their own job defined.
jci was an experiment on making documentation quick and easy to use. You
could have a document somewhere that listed out all the CI jobs and what they
did, but no one would take the time to go find that, and when there are new
ci jobs, who is going to go find that list and update it; or when the ci jobs change?
But if you have a tool that is right there next to where you are working that
will tell you exactly where to go for the context you are in, I would assume
people would type the 3 letters jci instead of going off to figure out what CI to run,
even if they knew exactly what ci job the needed, typing jci just takes you directly to it.
I like the concept of moving documentation closer to the tools you are already working with, and I'm going to see If I can find more places where I can make documentation more usable like this.
You can get the script here: github.com/analogpixel/jci, and
you can get the usage from running: jci -h