change out .devcontainer content for Codespaces environments

[emily-potyraj]

Current state

This change enables support for running the tutorials directly from the terminal inside Codespaces.

Pre-installed:

• rad CLI
• kubectl
• Azure CLI
• Radius VSCode extension

Note: This implementation is based on VSCode's universal:1.3.0 image, which consistently takes ~2 min to build for me when launching a new Codespace.

Futures

• add a doc page for it à la Dapr's: https://docs.dapr.io/developing-applications/ides/codespaces/

Still under investigation:

• How to test browser steps of tutorials from within Codespaces? Microservices tutorial is decent since you can just curl to get the messages. The Web App tutorial is much less cool without a browser :/
• Support running Radius inside a docker container inside Codespaces (2 possible paths: figure out running Azure CLI inside Ubuntu containers or add Alpine linux support in Radius)
• Which version of the rad CLI do we want installed in the Codespace? latest packaged build or latest code on main?
  • Currently set to latest packaged build.
  • The root workspace of the Codespace is whichever branch the user launched the Codespace from.)

[AaronCrawfis]

I think we may need to have two different containers for codespaces and containers:

1. A dev codespace with everything you need to develop for Radius, both code and docs. This includes go, hugo, .NET, etc.
2. A lightweight tutorials/demo codespace with only the minimum packages in order to launch quickly. This would also include extensions and documentation tailored for a walkthrough of Radius. It could also have https://marketplace.visualstudio.com/items?itemName=vsls-contrib.codetour

[rynowak]

I think we may need to have two different containers for codespaces and containers:

1. A dev codespace with everything you need to develop for Radius, both code and docs. This includes go, hugo,  .NET, etc.

2. A lightweight tutorials/demo codespace with only the minimum packages in order to launch quickly. This would also include extensions and documentation tailored for a walkthrough of Radius. It could also have https://marketplace.visualstudio.com/items?itemName=vsls-contrib.codetour

I agree that these are two different things.

2 is absolutely a priority now because this helps people try Radius out. Things like "how do I install the VS Code extension" are blockers right now for getting good feedback on Radius and won't be blockers long term. My understanding is that this is what the PR accomplishes (let's do it!).

For 1 (devcontainer for working on Radius) I want to know who the audience is before we invest time into it. This will require ongoing maintenance so we should do it when there's a good reason to. For example if/when Radius becomes a public OSS project, and we want to lower the barrier to contributing that's a good motivation.

I can be outvoted on 1 of course if folks want to use a devcontainer to work on Radius. Then by all means, feel free 😆 I don't personally plan to use it since I have a setup I'm happy with already.

[rynowak]

Note: This implementation is based on VSCode's universal:1.3.0 image, which consistently takes ~2 min to build for me when launching a new Codespace.

It should be possible to optimize away some of this by publishing a base image to our registry. If we know more about what steps are costly it should be possible to factor this into separate images so that it doesn't have to build on your machine. For instance I think the Azure CLI ends up being quite large.

[rynowak]

* How to test browser steps of tutorials from within Codespaces? Microservices tutorial is decent since you can just curl to get the messages. The Web App tutorial is much less cool without a browser :/

https://docs.github.com/en/github/developing-online-with-codespaces/developing-in-a-codespace#forwarding-ports

This should work ok. If it ends up being a true blocker then we'll prioritize making our tutorials expose a public port. There's nothing stopping us, it's just work to do.

[rynowak]

* Support running Radius inside a docker container inside Codespaces (2 possible paths: figure out running Azure CLI inside Ubuntu containers or add Alpine linux support in Radius)

We should use debian or ubuntu for the dev container. Alpine is so minimal that users will likely miss common userspace programs that aren't installed by default.

We can add support for Radius on alpine we have a strong need to in the future.

[rynowak]

* Which version of the rad CLI do we want installed in the Codespace? latest packaged build or latest code on `main`?
  
  * Currently set to latest packaged build.
  * The root workspace of the Codespace is whichever branch the user launched the Codespace from.)

I think we should make the publishing of a base image part of our build. This allows us to have the images follow our branching conventions and tags.

So for instance when you commit to the repo we build and push a new image for radius-rp. I think we should do the same for a base image for the dev container. The FROM statement in the dockerfile for the dev container would refer to our base image.

[emily-potyraj]

updates:

• added a new git workflow to auto-build base Codespaces image (radius.azurecr.io/radcodespace:latest)
  • Codespaces will be able to pull from our registry via Codespaces Secrets.
  • startup time for users launching Codespace from our repo is 20-30 sec
• added port forwarding for port 3000
• added a Radius-specific welcome in the Codespace that points to our docs

future enhancement ideas from this PR split out into: https://github.com/Azure/radius/issues/198

[AaronCrawfis]

We should create a Dockerfile outside of .devcontainer that builds our tutorial image, and then create a GitHub workflow that builds the container on each change and pushes to our radius container image that is configured for public access

[emily-potyraj]

Ok, looks like I had a problem as a noob VS Code user. For some reason, the github workflow I made to auto-build and push to the radius.azurecr.io regsitry came into my branch at origin as an empty file. Fixed now.

[emily-potyraj]

We should create a Dockerfile outside of .devcontainer that builds our tutorial image, and then create a GitHub workflow that builds the container on each change and pushes to our radius container image that is configured for public access

@AaronCrawfis totally agree. This is what the code is meant to do now that I fixed my push issue for the github file. Sorry about that. And luckily we don't even have to configure anything for public access.

[emily-potyraj]

4/20 changes:

• merged previous codespaces.yaml into build.yaml
• make codespaces build depend on rad CLI "publish" github action.
  • We're still going to pull down the published binary when building the codespaces env image to simulate end user workflow.
• unify all docker image build & push jobs on docker/build-push-action with caching (https://github.com/docker/build-push-action)
• remove the 2 docker-related tasks from Makefile
• push EOL changes github thinks a few files need (just SUPPORT.md & files from this PR)

We'd also discussed adding some fancy footwork for docs-only PRs to build.yaml while I was adjusting it. I tried a couple things with no luck and decided not to hold up the Codespaces work with that change. Tracked here now: #280.

---

TODO in github after merging:

1. Add DockerHub credentials & registry name as 3 secrets in this repo's Settings > Secrets > Codespaces Secrets. Enables pulling our published Codespaces image from our private registry when users launch a Codespace.
2. Change required pre-merge checks:

• remove "Container image build (acr)" and "Container image build (dockerhub)"
• add "Container image build", which includes build & push for both targets

[emily-potyraj]

Labels
The following labels are currently applied to every image.

"Labels": {
    "org.opencontainers.image.created": "2021-04-26T05:05:24.957Z",
    "org.opencontainers.image.description": "Project Radius is an application model for serverless cloud native applications",
    "org.opencontainers.image.licenses": "MIT",
    "org.opencontainers.image.revision": "443c282a248cb752ca1ac0b6f761afef57cefbde",
    "org.opencontainers.image.source": "https://github.com/emily-potyraj/emily-radius",
    "org.opencontainers.image.title": "emily-radius",
    "org.opencontainers.image.url": "https://github.com/emily-potyraj/emily-radius",
    "org.opencontainers.image.version": "3.0.5-prerelease"
}

Labels are configurable if we want to adjust them.

Tagging Scheme

1. Full release tag

• Build pushes the image with four tags
  radius-rp:5.0.0
  radius-rp:5.0
  radius-rp:5
  radius-rp:latest
• Codespaces: same
  radius-codespaces:5.0.0
  radius-codespaces:5.0
  radius-codespaces:5
  radius-codespaces:latest

2. Prerelease tag

• Build: pushes 1 image tagged with the full version name
  radius-rp:5.0.0-prerelease
• Codespaces: same
  radius-codespaces:5.0.0-prerelease

3. Build of main

• Build: pushes 1 image tagged with “edge”
  radius-rp:edge
• Codespaces: same
  radius-codespaces:edge

4. PR

• Build: pushes 1 image tagged with PR#
  radius-rp:pr-27
• Codespaces: does nothing.

Btw, build.yaml is not currently relying on .github/scripts/get_release_version.py (but some other GitHub workflows still are).

[rynowak]

Btw, build.yaml is not currently relying on .github/scripts/get_release_version.py (but some other GitHub workflows still are).
Labels are configurable if we want to adjust them.

Where do these versions come from then? get_release_version.py is the thing we use for versioning, so I'm a little confused about why we'd change this.

---

Regarding versioning all-up, I'm open to changing how it's implemented, but I'm concerned about us adopting something we understand. Can we simplify this?

Here's what I think we need:

Push to main -> :latest
PR -> :pr-#
Tag like v0.1.0 -> :0.1 (major.minor)

[emily-potyraj]

@rynowak - I backed out the changes that converted the main container build to the newer buildx github actions.
Piping LDFLAGS through wasn't working properly, and this buildx actions change doesn't seem important enough block the actual Codespaces support.

• "Container image build" job in build.yaml should be unchanged compared to main
• Makefile should be unchanged compared to main
• Codespaces image build is inside build.yaml but it's a separate job. It uses the buildx setup with caching etc, since the build-push-action@v2 lets me specify a Dockerfile and build context/directory.
• Codespaces image tags are:
  • push to main: "latest"
  • PR: builds with REL_VERSION but doesn't push
  • tag: REL_CHANNEL

#322 is open for that additional change to pull the rad build directly.

[emily-potyraj]

based on our chat earlier this week, I opened a new issue #322 for that change to pulling rad directly

dismissing to convert previous request for change into just comments since that code is outdated.

[rynowak]

🍾 🚀 🥳