CI/CD Woes
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 ).
I have had problems with Github for quite a while. They have been training their AI, Copilot on our work. Didn’t like that, so I moved most of everything, including the adventure game over to Codeberg . I thought Codeberg would be a good answer for everything. As a repo tool, it is really good. However, when I began working on things like versioning, tags, producing artifacts for different operating systems, it all began to fall apart.
Though Codeberg has the ability to create a workflow that will respond to say, a pull request completion, or pushing a version tag, I found two problems that I don’t have a decent solution for them. One is that Codeberg has no workflow for a Microsoft OS artifact. As one that is writing in Java, I don’t want my user base limited. The second is that it took three weeks of work and failure to realize that Codeberg doesn’t appear to have a place to keep your artifacts once they are produced.
This was really the biggest problem. I could, though it was very inconvenient, use github just for producing Microsoft artifacts. But, having to either push everything to github ( after leaving ) or signing up at a new place to host the artifacts was just not acceptable. With reluctance, I moved the entire repo back over to github and set about learning Github workflows.
Which, I will say, was a good experience. I created three workflows to produce a Zip for Windows, an RPM for Redhat/Fedora/Almalinux distributions, and a .deb for Debian people. I thought about doing one for Arch, but then I realized they probably prefer compiling from source.
I do still ave to deal with the fact that the workflow syntax is very picky, and there are things that have to be figured out ( like RPM’s don’t like ‘-rc1’ versions ). Overall, it was a good final solution despite that Github is not where I would like to be. And, I have the releases that one can use right here.
The game engine needs its own post, but I will explain where we are currently. The engine can provide rooms to build a maze with items and treasure in each room. Some items can be taken, some cannot. There is also the ability to find a chest and open or close it. Chests and sacks can have treasures or items in them. Players can travel from room to room with commands. The last thing I am working on is the game ending conditions.
Learning and using CI/CD methods, to me was difficult. Not the actual methodology, but trying to figure out things that aren’t really well documented. It’s a task I have to learn as a developer, but it will not be one of my favorites. Happy coding, y’all!