Add VSCode devcontainer config #3083
Conversation
| # Install GraalVM | ||
| # This downloads all relevant GraalVM architectures at once, mostly because $TARGETARCH values don't map exactly to the release URLs. Since we're optimizing for developer experience here and not image size, this is OK | ||
| # GraalVM release links can be found here: https://github.com/graalvm/graalvm-ce-builds/releases | ||
| ADD https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-22.3.1/graalvm-ce-java17-linux-aarch64-22.3.1.tar.gz /graalvm/tarballs/arm64.tar.gz | ||
| ADD https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-22.3.1/graalvm-ce-java17-linux-amd64-22.3.1.tar.gz /graalvm/tarballs/amd64.tar.gz | ||
| RUN tar -xzf /graalvm/tarballs/$TARGETARCH.tar.gz -C /graalvm --strip-components=1 | ||
| ENV JAVA_HOME=/graalvm | ||
| ENV PATH=$JAVA_HOME/bin/:$PATH |
There was a problem hiding this comment.
Why do we need both architectures? I thought the point of Docker was that you can run everything as if it were running on the Linux in the container.
There was a problem hiding this comment.
You can run, for instance, x86 containers on arm64 machines (or at least, on Apple Silicon). The main downside to doing so is performance (since this probably works by running in something like QEMU), so it's always preferable to have your container be the same architecture as your host system (which is achieved via the --platform flag in the FROM command).
|
I personally using nix as the development environment, which provides a better support to multi-arch, if using |
|
I haven't great experiences with nix-in-docker and VSCode (I'm actually exploring this for a different Codebase I'm involved with, and have played with the repo you linked). If you can get it to work, that is great! My gut feeling though is that it will be more complicated and have more dependencies (for example on the person maintaining nix-devcontainer). |
IIRC, I did some black magic on mill bsp. I will check that after back to my office. |
jackkoenig
added
the
Please Merge
|
Any clues on what the merge failure is about? It says something about me not being a user. I have already contributed to Chisel, so not sure what is happening. |
I think there must be a Mergify bug. There is a Premium Plan Feature to impersonate Github users when updating pull requests, but I'm pretty sure we're just using the free open-source edition of Mergify and it uses its own account to update PRs in this repo (eg. see #3056 (comment)). If we were able to and using that feature, then the docs say "The user account must have already been Anyway, I'll just update the branch manually--we also should consider not requiring PRs to be up-to-date. I wish we could require PRs to be "up-to-date-ish", like CI has been run in the last 3 days or something. |
|
Github has merge queues now, maybe that's a better answer to reduce CI churn while still testing that PRs are up-to-date. |
|
Thanks! GitHub merge queues sound interesting, you know I’m all about fewer dependencies :) |
jackkoenig
added
the
Internal
Contributor Checklist
docs/src?Type of Improvement
Development ease-of-use improvement.
API Impact
None
Backend Code Generation Impact
None
Desired Merge Strategy
Squash
Release Notes
Added standard config for VSCode dev containers that can get developers up and running with just Docker and VSCode. To use, simply open the repo in VSCode and choose "Rebuild and Reopen in Container".
Reviewer Checklist (only modified by reviewer)
3.5.xor3.6.xdepending on impact, API modification or big change:5.0.0)?Enable auto-merge (squash), clean up the commit message, and label withPlease Merge.Create a merge commit.