-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add devcontainer #359
Add devcontainer #359
Conversation
.devcontainer/Dockerfile
Outdated
@@ -0,0 +1,2 @@ | |||
FROM debian | |||
RUN apt update && apt -y install python3 python3-venv python3-dev make gcc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reckon the idea here is great, but it seems at this point, we'd have 3 paths for build:
- The "official" one at GH actions https://github.com/facebook/TestSlide/blob/main/.github/workflows/build.yml
- The already existing Dockerfile https://github.com/facebook/TestSlide/blob/main/Dockerfile
- The new Dockerfile added by this PR.
It looks like we'd benefit from having a single way of building the project.
The GH Action ("official") is based on Ubuntu-latest, and simply install the required python version and virtualenv. Perhaps, if the logic for these 2 steps is moved to the Makefile (eg: use pyenv), then we could have:
- GH action simply calls the Makefile.
- A single Dockerfile, which also calls the Makefile.
- Both based on the same ubuntu version (not "latest").
It seems this would enable us to have more reproducible builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forget why I created a second Dockerfile, I think it was a good idea at some point in the middle of my experimentation, but it isn't needed - I've updated the devcontainer config to use the existing Dockerfile
(I agree with the other points, but think they belong in separate PRs, I might do those later if I still have time at the end of the hack week)
Summary: Use venv rather than virtualenv venv has been included as part of the python standard library since 3.3 -- no need to install the third-party virtualenv module --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/TestSlide/pull/357). * #359 * __->__ #357 Pull Request resolved: #357 Differential Revision: D55365458 Pulled By: shish fbshipit-source-id: 0312bd52e37ba4d78572dcd2d616578dd820a92f
So that one merely needs to open the project in a supported editor (vscode, github) and the editor will pop up a prompt for "would you like to develop this project inside the container?", and if you click yes then you are straight into a known-good dev environment where you can run "make" and run all the tests
@shish has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Add devcontainer
So that one merely needs to open the project in a supported editor (vscode, github) and the editor will pop up a prompt for "would you like to develop this project inside the container?", and if you click yes then you are straight into a known-good dev environment where you can run "make" and run all the tests