fix: General Fixes

[JasonN3]

• [X] Add a VSCode Dev Container for easier development
• [X] Create standard for workflow names. build- test-
• [X] Rename Dockerfile to Containerfile to match other repos
• [X] Update build workflow to use Containerfile instead of Dockerfile
• [X] Generate multiple images. One for each version 38, 39, and 40 (n +/- 1)
• [X] Move build workflow to action.yml
• [X] Update .gitignore for new resulting ISO path
• [X] Add .github/CODEOWNERS
• [X] Standardize Makefile variable format
• [X] Update README.md with information
• [X] Rename resulting ISO to @IMAGE_NAME@-@IMAGE_TAG@ to match container that gets deployed

[noelmiller]

@castrojo @bsherman @KyleGospo @EyeCantCU Since this is a larger change that uses https://github.com/ublue-os/build-action as a key building block, I need more folks than just me to weigh in on this PR.

@JasonN3 to clarify for everyone, build-action would ultimately be replacing individual build.yml files with one unified action?

• build.yml in main
• build.yml in Bazzite
• build.yml in Bluefin

If the above is true, I would like to discuss the advantages and disadvantages of the approach of using one unified build action with a matrix for all separate repos, vs each repo having their own build.yml actions defined.

[JasonN3]

Yes, the intended purpose of build-action is to unify all of the build processes. Right now the same workflow is copied to multiple repos and then modified and some variables are used in the same way but with different names. Some workflows also have features that other workflows don't but could have. The end goal for that repo is to replace all of that with a call to a central action that will surface the same capabilities to all of the repos. That repo started off based off the workflow in bazzite and then was tested against main and bluefin as well as this repo. This is the first repo actually using it though. Adding it into the other repos would be a gradual process that would be done one repo at a time to ensure the builds do not break or change.

[JasonN3]

To clarify something else, the build-action repo workflow won't build the container images. It is just an action to be called by the rest of the repos, just like isogenerator. Each repo will still have a matrix to define the parameters for building.

[bsherman]

To clarify something else, the build-action repo workflow won't build the container images. It is just an action to be called by the rest of the repos, just like isogenerator. Each repo will still have a matrix to define the parameters for building.

I think I see how things are interrelated here, but I'll state my understanding for confirmation.

As of this PR, isogenerator repo has: the primary product:

• an action to be consumed by workflows (ublue image repos) which will generate an iso from said container images

self-testing:

• workflow build-container-image uses build-image action (from the repo of the same name) for building an isogenerator:VERSION OCI image, published to ghcr (actually contains some ublue image)
• workflow test-iso which uses both the above isogenerator action and the above generated isogenerator:VERSION OCI image to generate ISO images for testing.

While blue-image action is consumed here, implementing it in other repos is not a direct requirement for this PR, and as you said, @JasonN3 , we can handle that over time. I think that process is a distinct question from the implementation of this isogenerator PR, so we can discuss the details on that effort as appropriate.

Is this a fair summary of the PR?

[JasonN3]

To clarify something else, the build-action repo workflow won't build the container images. It is just an action to be called by the rest of the repos, just like isogenerator. Each repo will still have a matrix to define the parameters for building.

I think I see how things are interrelated here, but I'll state my understanding for confirmation.

As of this PR, isogenerator repo has: the primary product:

* an action to be consumed by workflows (ublue image repos) which will generate an iso from said container images

self-testing:

* workflow `build-container-image` uses `build-image` action (from the repo of the same name) for building an `isogenerator:VERSION` OCI image, published to ghcr (actually contains some ublue image)

* workflow `test-iso` which uses both the above `isogenerator` action and the above generated `isogenerator:VERSION` OCI image to generate ISO images for testing.

While blue-image action is consumed here, implementing it in other repos is not a direct requirement for this PR, and as you said, @JasonN3 , we can handle that over time. I think that process is a distinct question from the implementation of this isogenerator PR, so we can discuss the details on that effort as appropriate.

Is this a fair summary of the PR?

Close.
You're right onbuild-container-image.
test-iso does not use the container image. It just uses the action (action.yml) from this repo.

build-container-image: Calls the action build-action to create an OCI image for this repo using Containerfile and push to ghcr.io/ublue-os/isogenerator:$INSTALLER_VERSION. INSTALLER_VERSION can be different than the version of what gets installed. It just indicates which version of Fedora the installer will be built from.

test-iso: Calls the action isogenerator to create an ISO for ghrci.io/ublue-os/base-main:$VERSION. The resulting ISO gets attached to the workflow run, but isn't used for anything other than potentially verifying that it was built correctly.

The container image is just being built for development work. I don't really care for it since everything is already in the Makefile, but it was wanted, so I left it in there. However, calling it as the workflow makes it harder to debug and has the potential to result in the wrong version being run, so I kept the individual make commands for the workflow.