-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
feat: Dev Container for consistent dev setup #5143
base: main
Are you sure you want to change the base?
Conversation
85c920e
to
4908b57
Compare
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.
This is likely to quickly get outdated. I think this may be a bit out of scope for this repo. Could you find a better place for this? And maybe we can have a link for it in our readme
Thank you @ThomasRaoux for your feedback. Also, could you elaborate on why improving the onboarding experience for developers might be considered out of scope? The purpose of including the dev container in the repository is to provide a consistent development environment across various setups. This consistency benefits both new developers during onboarding and existing contributors. If the dev container is part of the repo, any updates to the project are automatically reflected in the dev container immediately. |
d2760bf
to
68f47d1
Compare
sorry for the slow response. My concerns is that when something change in the flow those files are not going to be updated and will be staled. |
No problem. How frequently does the Triton flow change? The dev container files typically need updates only when there’s a significant change in tooling or dependencies. To further mitigate concerns, I’d be happy to take responsibility for updating these files if the development environment changes significantly. Even if these files aren’t updated immediately with every future change, they won’t negatively impact the core application. At worst, they might require minor adjustments later, but their inclusion now ensures a more consistent developer experience.. |
Added a Dev Container configuration to streamline development and onboarding. This setup ensures a consistent, isolated environment with all necessary tools and dependencies for building and running Triton. Signed-off-by: Maryam Tahhan <mtahhan@redhat.com>
Improve the Dockerfile to separate out the LLVM build stage and trigger the build through a simple argument in `devcontainer.json` to lower the barrier to entry to devcontainer use. Signed-off-by: Maryam Tahhan <mtahhan@redhat.com>
68f47d1
to
9fc2d5d
Compare
Added a Dev Container configuration to streamline development and onboarding. This setup ensures a consistent, isolated environment with all necessary tools and dependencies for building and running Triton.
Edit: I updated the Dev Container to enable the LLVM build based on a flag in
devcontainer.json
rather than editing theDockerfile
directly. This should lower the barrier to entry for using containers for new users. Additionally the LLVM build now pulls the commit id fromcmake/llvm-hash.txt
or the user can edit the COMMIT directly.New contributor declaration
I am not making a trivial change, such as fixing a typo in a comment.
I have written a PR description following these
rules.
I have run
pre-commit run --from-ref origin/main --to-ref HEAD
.Select one of the following.
/test
forlit
tests/unittest
for C++ tests/python/test
for end-to-end testsit's to do with the developer workflow and onboarding rather than a code change
.Select one of the following.
lit
tests.lit
tests I have added follow these best practices,including the "tests should be minimal" section. (Usually running Python code
and using the instructions it generates is not minimal.)