[Tracking] Onboard additional definitions to image build

[Chuxel]

After #140 is complete, we can start to on-board more images. In some cases, changes to the definition are required while in others it's a matter of going through the process.

On-board to automatic image generation

Need to coordinate with the appropriate teams where applicable. In some cases, the team may prefer to build their own images - which works just fine as well.

• Base images (Debian, Ubuntu, Alpine)
• Azure Functions - Coordinate with appropriate teams/authors. @jeffhollan @fiveisprime @testforstephen @brunoborges @anthonychu @brettcannon Functions team is looking into doing their own images rather than building out of this repo.
• C++
• .NET Core - Coordinate w/ .NET team. Needs custom stub to allow Node.js / Azure CLI install. @richlander
• F#
• Go Onboard Go image to build #492
• Java - Coordinate w/ Java team @testforstephen Onboard java to build #493
• JavaScript & Node
• PHP
• Python - Coordinate w/Python team. @brettcannon
• Python Anaconda/Miniconda Onboard Anaconda and Miniconda to image build #545
• Ruby
• Rust
• TypeScript & Node
• Universal (Codespaces)

Others less used definitions to consider:

• Dart
• Perl
• R
• Swift
• PowerShell

Incoming to consider:

• Incoming Julia definition should have its own pre-built image (See Add Julia devcontainer #450).
• Azure Machine Learning team is looking at the Azure ML definition to determine whether they want to pre-build their own.

Update to base off of MCR image (once available)

Need to coordinate with 3rd party author where applicable.

• Azure Ansible Update azure-ansible to use common scripts #472
• Azure Blockchain
• Azure CLI Update rust, bazel, perl, azure-cli, R definitions to use common scripts #473
• Azure Terraform
• Bazel Update rust, bazel, perl, azure-cli, R definitions to use common scripts #473
• dapr-typescript-node-12
• Elm
• Jekyll
• Markdown
• PHP & Maria DB
• Python & Postgres
• Node & Mongo
• Node & Postgres
• Ruby Sinatra, Ruby on Rails

Salesforce, Puppet image is maintained by companies already.

[brettcannon]

I can help with the Python ones (and I'm totally fine with automatic generation), but the Functions ones are probably best left up to the Functions team (who know me and can loop me in as necessary).

[Chuxel]

@brettcannon Thanks Brett! One question for the Python definitions is whether just doing latest for Python 3 is enough if we pre-build images. People will be able to easily get back to the Python Dockerfile to use it if they prefer (the build system will add links into devcontainer.json and the stub Dockerfile that gets added), but do we need sub revisions? (e.g. Python 3.8, 3.7, 3.6)

[TylerLeonhardt]

I'd like to understand the work involved here to onboard. Can you summarize @Chuxel?

[brettcannon]

@Chuxel it's such a per-project choice that for your own sanity I would just go with latest and expect people to manually tweak as necessary if they need a different version. But if you're feeling generous then you could list support for all versions supported upstream.

[anthonychu]

For Python Azure Functions, we'll probably want to keep it at 3.6 for another week or two, then update it to 3.7 once the next Azure Functions extension is released with better 3.7 support. I created that dev container so I'm happy to help with it and any of the other Azure Functions ones.

[Chuxel]

@brettcannon Yeah, that was kind of my thinking as well. With Node we're doing ones for in support LTS versions, which is typically only two - 10, 12 (8 is going away very soon). Anything that is more of an example like the node-mongo is just latest LTS. For Python, we could start with latest major version (e.g. 3 -- since 2 is about out of support) and just use a tagging scheme to make it easy to add others if needed. (e.g. mcr.microsoft.net/vscode/devcontainers/python:3 rather than python-3)

@anthonychu Sounds great! One of the things this new setup also does is allow the use of common script (though currently only one per Dockerfile). I've got basic scripts to install common things like git, zsh, etc for the trial set. Once those are up I can let everyone know in the event that makes it easier to maintain the different variations of the Functions ones.

@TylerLeonhardt Most of the actual build is automated, so really the discussion is:

1. Are there definitions that should not have images pre-built via this repo? (e.g. The Salesforce definition uses an image they're managing. Similarly, an alternative for PowerShell is to reference one built and managed elsewhere - entirely open to either approach.)
2. How many variations should be pre-built? To Brett's point, this can get out of hand quickly. The output of the build process also will have links to the Dockerfile so people can build their own, so the question is the most common scenarios.
3. We do have to think about what is included in the images, so for anything external that is not OSS, we'll need to verify we are okay including them. Similarly, the images would be MIT licensed, so if there's concerns about our own bits, we'd want to talk about that. (Registering is also somewhat automated, so more a due diligence question.)
4. What naming scheme do we want to use for the images? We can have multiple definitions publish to the same image repository with different tags, so there's no requirement that a single definition map 1:1 with an image repository. Typically, I'd assume powershell:${PWSH-VERSION} rather than powershell-${PWSH-VERSION}, but in some cases it's a bit more complicated.

I haven't merged in the changes since I'm OOF this week, but ultimately there's effectively a json config file that can be dropped in a definition folder along with an update to a MCR feed that causes it all to happen.

I'll provide more specifics soon!

[JJ]

Can help with Perl if needed.

[Chuxel]

At this point I'm going to close out this issue in favor of new ones on an as-needed basis. We have the core images that Microsoft is focusing on maintaining at this point. Pre-building community contributed definitions is not something we plan to do because of a combination of lack of knowledge and a need for a full-time maintainer that also is managing security patching.