How to screw up CI/CD without really trying

It begins

Yes, I am way behind on writing. RL keeps invading and I spent so much time recently trying to figure out how to create workflows that would showcase my work on an app.

I have a small Java console text adventure game I am working on. The goal is not the game, but the engine and the process of developing software. I am approaching a major point in the development. I am nearly at V1.0. I have someone that is testing the playability of the software. Having just a regular repo isn’t enough anymore. I needed something more robust. So, I started learning some of the things to do with CI/CD ( continuous integration, continuous development ).

Now I understand bloatware

I have not written in a while, which is not good. But, I have been so busy between RL work and my software work that I just have not had the energy or time. When I am at home, I have been working on learning how to package my adventure game. It is not as easy as it looks. I would liked to have written this post as a mini-howto on packaging via jpackage, codeberg, and github. Yeah, it’s not happening yet.

Background and beginning

If you read my previous post, you know that I recently spent a good deal of time debugging a Java build of a program. Not a bug in the Java code, but a bug in gradle, my build environment. Specifically, in my gradle build file: build.gradle.kts.

After going through that problem, I spent time, finally, not pursuing more programming, but learning how gradle’s build operated instead. So, this is a summary of that learning. Sorry, it’s going to be a bit long. But, first, I need to take a minute to go over background things so that we are all on the same page. If you read my post about writing and compiling a Hello World! program in C and in Java , you will know what a basic Java program looks like. You will also see that, in theory, you can compile a Java class with javac MyMain.java into a program.