Dockerfile Generator app, Dockerfile Database app + Database API created

[KidWizardOfTheWeb]

Dockerfile management suite - an example of QA resource management apps

I decided to create two apps, both with the goal of improving the QA testing environment when used together. Both apps center around a Python based environment and the usage of Dockerfiles for the sake of this project, but can be extended to other services in the future such as external databases and image registries.

Using Claude and Opus 4.5, I generated an app that is designed to create Dockerfiles, and another app for storage of Dockerfiles and other text based documents. If these projects were to be extended in functionality as intended, I think they could provide an interesting testing management/database record solution.

App 1: Dockerfile Generator - A generator for setting up containerized applications

Click on me for instructions for running the app

Testing suite information can be found by clicking on this link

The Dockerfile Generator takes in a Python script and generates a Dockerfile based on imported modules, the minimum version of Python needed, and anything else required by the script itself.

Originally, Claude generated 100% of the Dockerfile generator. However, it was missing some detection components, especially in the minimum Python version required fields (Claude didn't account for this, and set the minimum required version to 3.11 no matter what for all Dockerfiles).

To rectify this, I used the Vermin package. This package is designed to read Python code provided by either a file or series of files, and based on the provided information, return what minimum version of Python is required. At first, I had Claude attempt to implement this on it's own. However, it used the package erroneously. The implementation it attempted used the Vermin API, which did not work in the intended way.

I proceeded to implement Vermin on my own using a subprocess (which is the intended way to use it currently), and fixed the issue of the Dockerfile not having the correct minimum version used. Depending on the flags used in the CLI command for this application, you can include extra imports a script may use, which will give a more accurate minimum version of the script if it's based on an entire project. I ended up testing this on my own personal Python project (Reaper Co. Mod Manager), where it correctly detected the minimum version needed of Py 3.12 when using the --scan-imports flag.

Generating a Dockerfile is good in case you don't want to write the specs yourself to create your containers, but the true intention of this application is to generate a Docker Image instead, which would provide a containerized application for testers that could be managed with the next app. For this project, I did not implement this due to the user needing WSL and Docker installed. Installing WSL requires admin permissions, and I would currently not elect to force that on the person testing this application. Do know that the functionality can be implemented later on, as an extension of this application or as a separate, lightweight script.

App 2: Dockerfile Database + API - A way to store Dockerfiles and other data on tested applications

Click on me for instructions on running the app

Testing suite information can be found by clicking on this link

See the API reference here by clicking on this link.

With generated Dockerfiles, the point is to allow users in a repository to generate their own Docker Images. Even though I currently could not provide Docker Image generation from the last app (see the final clause in the App 1 section), Dockerfiles fill in for that purpose for this app.

I put myself in the position of a QA tester for this app, imagining how easy it would be to track versions and changes to an application if we could timestamp builds and pass them around easily. While Github can do this with Github actions, I made my own version with the Dockerfile Database.

In the Dockerfile database, a user can insert a Dockerfile of their choice into a locally created sqlite3 database. The Dockerfile is stored with the name of the file, the timestamp, and the data inside of it. The requirements of this project requested the app to be ran locally, so for now, the application handles all database read/write operations locally. The database functionality can be extended to other services like an AWS based database in the future.

The idea of this application is that QA testers can send and retrieve versions of an application using a database to timestamp changes. What's even better with this database is that you can store more than just Dockerfiles, as any text based file is completely compatible as well. A possible usecase of this can be chained with the Dockerfile generator's true intention, where a developer can chain creating a Dockerfile, generating a Docker Image, pushing the Docker Image to something like AWS ECS, and committing test notes/results/data to the database on the specific Docker container. All of this is timestamped and accessible by the Dockerfile Database API.

The database API can store files, as well as retrieve and filter them by date and name. There are simple statistics that can be viewed as well when the database is used in interactive mode.

Claude generated this application, with some major errors in testing. However, I could see the exact errors happening with the API, so instead of needing to reprompt, I fixed the API part of the tech stack. Mostly small errors such as checking for "not found" instead of "Resource not found", but also some parsing errors with date tests came up. It was extremely important to understand the data formats that could pass through the API, so knowing the test cases and how they work mattered a lot. It was definitely a good thing I have a ton of debugging experience over the years.

Retrospect

I made sure that the code generated by Claude was something that could be understood and expanded upon by myself and others. The most important thing to know about using codegen AI tools is structure, as just generating code as a means to an end doesn't mean anything if you can't explain or work with what was created by the AI.

It sped up my development by days when I used Claude code, and I only had to use about 4-6 prompts total between both apps to create them. When it made mistakes, I was able to adapt and debug them easily using PyCharm's debugging tools and my previous experience on full-stack projects. After a while, you tend to figure out where to look for errors and narrowing it down becomes a lot easier.

Although I wish I could've written the documentation myself, Claude actually did that part for me. It was a little dense and verbose for my liking, it was thorough with the material it wrote.

Overall, I feel confident that it could produce solutions easily, as long as one knows how to put pieces together to construct the whole idea. Since I've done a few projects where I had to plan, develop, debug, and deploy the code, architecting a solution was my strong suit on this project, leading to fewer prompts needed overall and fewer bugs encountered due to how thorough the requirements I laid out were.