(feat): Add codespaces/devpod support

[csantanapr]

Adds support to be able to run idpbuilder on cloud dev environment

[nabuskey]

Thank you for this! Left some comments, please take a look

[csantanapr]

I had to remove forwardPorts from devcontainers.json as this prevented exposing port 8843 in localhost, it wanted only to expose to .github.dev host name. forwardPorts only worked for devpod.
User in both cases need to go to "ports" in the local vscode/ide and go to Ports and add forward port 8443 to 127.0.0.1
User will also need to add the /etc/hosts entry locally in laptop/workstation

127.0.0.1 argocd.cnoe.localtest.me
127.0.0.1 backstage.cnoe.localtest.me
127.0.0.1 gitea.cnoe.localtest.me
127.0.0.1 argo.cnoe.localtest.me
127.0.0.1 keycloak.cnoe.localtest.me

and any other hostname handle by nginx ingress

[nabuskey]

Some things I've noticed about trying to get it working in codespaces:

1. Codespaces creates a public proxy endpoint for processes running in codespaces. This is considered proxy dodging and very likely gets blocked by security software managed by organizations on local machines.
2. Because of above, ingress-nginx cannot route based on host names. For example, when I port-forward 8443, it creates an endpoint looking something like https://random-name-8443.app.github.dev. To access the port 8443 on codespace, we must use this url. This means we must use path based routing in our ingress instead of hostname based routing. e.g. instead of using argocd.localtest.me, do random-name-8443.app.github.dev/argocd.
3. This means we need to configure argocd to append /argocd to its root path. Otherwise, the client can't fetch resources from ArgoCD.

So if we want to get this to work in Codespaces flawlessly in browser, we need to configure our core packages for this purpose specifically. If GH CLI is used locally, it looks like you can do this without further tweaks.

[nabuskey]

User will also need to add the /etc/hosts entry locally in laptop/workstation

127.0.0.1 argocd.cnoe.localtest.me
127.0.0.1 backstage.cnoe.localtest.me
127.0.0.1 gitea.cnoe.localtest.me
127.0.0.1 argo.cnoe.localtest.me
127.0.0.1 keycloak.cnoe.localtest.me

This shouldn't be necessary and we probably should not ask users to do this because organization security policies may not allow this kind of modifications. The domain names *.localtest.me does resolve to 127.0.0.1 as long as the registered NS is reachable.

[csantanapr]

@nabuskey I agree it would be better experience to have idpbuilder work with the external hostname given by Codespaces.
Reading the docs is not a random-name but the https://CODESPACENAME-PORT.app.github.dev according to the docs [1] the CODESPACENAME is a environment CODESPACE_NAME available from the environment [2]

I think is matter telling the user to find and replace in the yamls host: argo.cnoe.localtest.me with host: $CODESPACE_NAME

I will test this setup

[1] https://docs.github.com/en/codespaces/developing-in-a-codespace/forwarding-ports-in-your-codespace
[2] https://docs.github.com/en/codespaces/developing-in-a-codespace/default-environment-variables-for-your-codespace#list-of-default-environment-variables

[csantanapr]

Just realized even if we can predict the hostname, we will need different ports or path to route at the ingress with a rewrite to / when sent to backend

[csantanapr]

I think this is ready for merging, is a very basic dev environment for go, and if user wants to use idpbuilder is also has docker in docker that user can use idpbuilder

[csantanapr]

@nabuskey please take a look I addressed your feedback. The files now contain the absolute minimum for an user to use codespaces, devpod, docker, to have a golang environment to make changes to idpbuilder and test

[nimakaviani]

LGTM!

defering to Manabu to squash and merge.

[nabuskey]

LGTM