Create Standardized Local Development Environment

[noelmiller]

I was talking with Jorge in the discord and getting a standardized local development environment set up would make it much easier to onboard folks. The biggest hurdle I found working with this project is not having an easy way to configure a development environment using automation.

Current process:

1. Create Local Container Registry
2. Download ISO for Silverblue and install on your VM
3. Add configuration information to point to local registry
4. Rebase onto your locally built container image

Proposed Process:

1. Install Ansible
2. Run Ansible-Playbook
3. Development environment is up

What will the playbook do?

1. Download CoreOS Image based on your hypervisor and use ignition file to rebase on your local repository

Anyone have any thoughts on this?

[castrojo]

cc @ublue-os/approver @ublue-os/member

[bsherman]

This sounds pretty similar to https://github.com/ublue-os/forge except without the PXE boot stuff.

[bsherman]

I would be interested to see what you come up with, as I am not seeing how this is a "development environment". Happy to have more explained to me though. :-)

I do think it sounds interesting as an easy way to get a local container registry running. That can be very valuable since local builds avoid costly/slow downloads from GHCR. As I see it, this would still require the user/developer to be doing manual podman build with appropriate build-args to run all the correct options, and then podman push, though obviously it could be scripted.

So, that's helpful, but IMO, the more challenging problem is the Github Actions workflows. We rely on them heavily, and they are often a pain point.

I've done some playing with https://gitea.com/gitea/act_runner, a fork of https://github.com/nektos/act ... At least in the gitea fork, there's some problems related to cgroups, when trying to run our Actions workflows under act_runner in nested containers. If this could be solved so act could run our workflows locally, then we'd have a pretty huge benefit of being able to run a full set of local builds for dev/test.

[noelmiller]

I'm going to revisit this issue with some new ideas I've had. This project is exactly the sort of thing that I was hoping would exist one day:
https://github.com/osbuild/bootc-image-builder

It's not quite ready, but the idea I have here is once it can support local container registries the workflow for onboarding someone new would look like this:

1. Run First Time Setup Ansible Playbook (or shell script if we prefer that)

This would setup the following: (supported on Linux only for the time being)

1. Local container registry with the project you want to develop on.
2. Create a qcow2 image and make it available inside of Virt Manager
3. Anytime you make any changes to the container registry, your virtual machine should see those changes and you can reboot it to reflect the changes.

I know most folks like to just use containers to develop this project, but VMs are awfully nice for troubleshooting UI related issues or testing things related to that.

[dosubot]

Hi, @noelmiller,

I'm helping the Main Repos team manage their backlog and am marking this issue as stale. You proposed creating a standardized local development environment using Ansible to streamline onboarding for new contributors, which would automate the setup process with a single playbook. In the comments, @bsherman expressed interest but raised concerns about the definition of a "development environment" and highlighted challenges with GitHub Actions workflows. You also mentioned revisiting the issue with new ideas, including integrating local container registries and virtual machines for better troubleshooting.

Could you please let us know if this issue is still relevant to the latest version of the Main Repos repository? If it is, feel free to comment here to keep the discussion alive. Otherwise, you can close the issue yourself, or it will be automatically closed in 7 days.

Thank you!