Devcontainer

[brettmillerb]

Added a Debian devcontainer with the following:

• Buster image
• PowerShell 7.0.3
• Azure CLI
• Bicep Latest
• Bicep VSCode extension

This should be usable with newer versions by just rebuilding the container to pull the latest releases when needed.

[codecov-commenter]

Codecov Report

Merging #455 into master will decrease coverage by 0.86%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #455      +/-   ##
==========================================
- Coverage   91.93%   91.06%   -0.87%     
==========================================
  Files         199      201       +2     
  Lines        6708     6784      +76     
==========================================
+ Hits         6167     6178      +11     
- Misses        541      606      +65     

Flag	Coverage Δ
#dotnet	91.06% <ø> (-0.87%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/Bicep.Core/Emit/TemplateWriter.cs	100.00% <0.00%> (ø)
...c/Bicep.LangServer/Completions/SymbolExtensions.cs	0.00% <0.00%> (ø)
...icep.LangServer/Handlers/BicepCompletionHandler.cs	17.85% <0.00%> (ø)
src/Bicep.LangServer/Server.cs	90.32% <0.00%> (+0.32%)	⬆️

[alex-frankel]

Thanks for the contribution!

I had to do a little bit of learning to understand the convention of the .devcontainer folder. It looks like it's specifically for VS Codes "Remote" extension and it also applies to github codespaces. Are there other applications?

The container started up correctly and bicep was installed, but I got an error in VS code when it tried to install .NET:

Not sure if that is an issue with this PR, or how we installed .net core for the bicep extension, or if this only happens in VS Code - Remote and wouldn't happen in codespaces.

[brettmillerb]

Thanks for the contribution!

I had to do a little bit of learning to understand the convention of the .devcontainer folder. It looks like it's specifically for VS Codes "Remote" extension and it also applies to github codespaces. Are there other applications?

Not sure if that is an issue with this PR, or how we installed .net core for the bicep extension, or if this only happens in VS Code - Remote and wouldn't happen in codespaces.

Hmmm I've not tried codespaces, I will have to do some more testing to see where that issue could lie.

[JayDoubleu]

Seems to work fine with codespaces.
No issues with DotNet, it seems that I had to re-open the codespace after build for extensions to be installed.
Also tried with code 1.49.0 remote containers on windows and it also works fine.

[brettmillerb]

Seems to work fine with codespaces.
No issues with DotNet, it seems that I had to re-open the codespace after build for extensions to be installed.
Also tried with code 1.49.0 remote containers on windows and it also works fine.

I'm on MacOS
1.49.0-insider
b6d4fec3714ff897f72c1dab8cc02b7421a8f131
x64

Just tested and rebuilt the container and all worked fine too, didn't see anything about dotnet runtime 🤷‍♂️

Just to be clear that this is for consumption of bicep and not for building running the development project in this repo and is basically a dockerfile translation of the installation steps in the README.

I appreciate this might not be the best place to host the definition but the release cadence of the Vscode remote development extension will likely take too long to get the latest artefacts.

Happy to publish this to a container registry if that would be better suited? @alex-frankel

I just wanted an easy way to test bicep without having to manage versions on my machine. This way allows me to rebuild the container and get the latest releases of both the extension and the bicep cli.

[JayDoubleu]

The whole point of devcontainer.json is that you dont have to push anything to any registry. I can simply point codespaces at this repository, go to docs/examples and start developing with bicep without doing anything.

devcontainer.json is usually present on most ms repos for that specific reason.

[brettmillerb]

The whole point of devcontainer.json is that you dont have to push anything to any registry. I can simply point codespaces at this repository, go to docs/examples and start developing with bicep without doing anything.

devcontainer.json is usually present on most ms repos for that specific reason.

Agreed.

[alex-frankel]

I would've thought that this feature is more for getting a dev environment set up for working on the bicep language service. That being said, I'm fine with this being here just as a way to get bicep up and running quickly. As a sidenote, we also have the bicep playground: https://aka.ms/bicepdemo

I just tried it again on a different windows 10 machine with VS Code version 1.49 and I am able to repro the .net install issue. If I close the VS code window and reopen with the container it is able to successfully install .net core and the extension runs perfectly.

So my main issue is that first-run error. I'm wondering if we can do a little digging to see why that might be happening? @majastrz / @anthony-c-martin thoughts on this one?

[anthony-c-martin]

Could the error be related to: dotnet/vscode-dotnet-runtime#98? (e.g. some miscellaneous error occurred when launching pwsh, which this package appears to have a dependency on)

@alex-frankel could you copy and paste the full error message from the dialog box? Looks like the interesting part has been cut off in the screenshot. There's also a log file that should have been created (should be referenced in the error), though I'm not sure how we can access it from the container image.

[alex-frankel]

OK, we had a long chat about this today :)

Our feeling is that we think the .devcontainer directory for this repo should be an image to set up a dev workstation to work on the bicep source code. It actually shouldn't have the bicep CLI or vscode extension because someone working on the bicep source should want to build those components locally.

For the scenario you are after, we'd prefer to do that in a dedicated repo that follows the vscode-remote-try-* naming convention. We could then gear the whole repo towards helping people jump into bicep -- the readme could be more focused, there could be good starter .bicep files in the root of the repo, etc. I personally would be really excited to use that for demos with potential bicep users.

So @brettmillerb we have a couple questions:

• if we set up a repo in the Azure org (Azure/vscode-remote-try-bicep), are you good resubmitting an equivalent PR there?
• would you be up for updating this PR to help get a bicep dev workstation up and running? No worries if you don't want to take that on, but figured we would give you first dibs on it

[alex-frankel]

New repo is here: https://github.com/Azure/vscode-remote-try-bicep

I decided to open it in the Azure org, but open to choosing the Microsoft org instead.

[alex-frankel]

@brettmillerb - thoughts on this one?

[brettmillerb]

OK, we had a long chat about this today :)

Our feeling is that we think the .devcontainer directory for this repo should be an image to set up a dev workstation to work on the bicep source code. It actually shouldn't have the bicep CLI or vscode extension because someone working on the bicep source should want to build those components locally.

Yes, this was why I asked my question originally as this wasn't exactly the ideal place for this to live but living in the Remote Dev Tools extension would limit the ability to update it.

* if we set up a repo in the Azure org (`Azure/vscode-remote-try-bicep`), are you good resubmitting an equivalent PR there?

* would you be up for updating _this_ PR to help get a bicep dev workstation up and running? No worries if you don't want to take that on, but figured we would give you first dibs on it

Yeah I can give it a crack with what I currently have and that repo with the devcontainer and the examples would be an awesome go to.

Will try and take a look before next week and get an initial PR submitted where we can discuss in more detail 👍

[alex-frankel]

Awesome - no rush. Thanks Brett!!

[anthony-c-martin]

Closing this out as we now have this functionality available under https://github.com/Azure/vscode-remote-try-bicep