search

ublue-os / main

OCI base images of Fedora with batteries included
https://universal-blue.org/images/main/
Apache License 2.0
468 stars 33 forks source link

Create Standardized Local Development Environment #378

Open noelmiller opened 9 months ago

noelmiller commented 9 months ago

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 commented 9 months ago

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

bsherman commented 9 months ago

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

bsherman commented 9 months ago

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 commented 6 months ago

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.