-
-
Notifications
You must be signed in to change notification settings - Fork 952
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
Unify docker devcontainer with dockerfile used for CI #1587
Unify docker devcontainer with dockerfile used for CI #1587
Conversation
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 think it would be nice to remove the .devcontainer
directory, and move the JSON to .devcontainer.json
in the root. We would need to move the documentation somewhere else though...
I would put the .devcontainer/README.md into docs/usingDevcontainers.md, maybe? |
Seems good to me. One more thing, make sure to add a trailing line feed to files, so that the diff doesn't complain. |
Oh, I thought that would be automatically done via the linter. Will do |
Nevermind. The linter automatically removes trailing newlines... Is that intended? |
Which linter are you using? clang-format should add trailing newlines, or at the very least not remove them. We mostly stick to having trailing newlines, and I think that almost all files already have them. (Keep in mind that clang-format is only for C/C++ files) |
Well, I am using the standard linter integrated into the devcontainer. The linter automatically removes trailing endlines at the end of .json files. |
Build size and comparison to main:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
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.
The currently active maintainers don't use the devcontainer, so you'll need to explain what these changes do.
Please read the commit conventions https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/doc/contribute.md#commit-conventions
Question: what exactly is the correct compiler we are using? I need to specify the compiler "executable" for Intellisense |
It's the one specified in the build instructions. https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/doc/buildAndProgram.md |
This pull request should be ready to merge now |
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.
Sorry it's taken so long to get around to reviewing this. I think that most of it is pretty good. I think it should be possible to get the executable paths etc. from build.sh
by exporting them to the environment.
Why are the checks failing? The logs imply a check called |
This check depends on another check, but they can't be run because there are conflicts. |
I have looked into extracting the compilerPath from If anyone knows if there is way to set VSCode extension settings based on exported variables in a .sh script that would be ideal, I did not find a way. |
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.
While it's not perfect, mostly due to the copying of variables, this fixes the devcontainer and improves its maintainability.
Uh oh, I see the PR now has 176 changed files, did I mess up the merge...? |
7cbc2a8
to
647b77e
Compare
@BloodStainedCrow I've just fixed that merge commit, so now I believe this pull request is in a good enough state to be squash merged. |
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.
Thanks for reducing redundancy. But the current version with hard coded paths breaks existing setups. Which isn't desirable
58715cc
to
0a0a4c3
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.
small open questions from my side. Everything else looking sound. I don't use the Dockerfile or the devcontainer, so I didn't check functionality.
Would love for someone else to chime in and do a review as well
// FIXME: This is hardcoded. I have no idea how to use the values set in build.sh here | ||
"gdbPath": "/opt/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gdb", |
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.
can the "GCC_ARM_PATH" variable be used here?
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.
As far as I know (see my previous attempts above) VSCode currently does not support loading variables for launch.json from anything but launch.json itself, which sadly means without some serious hacks, there will be this reference here, which might become outdated.
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.
Looking at this though, the very least I should do is unify the occurrences of it in a variable in launch.json so only one value can grow stale
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.
that would be very welcome, as it would minimize the staleness factor (if that is a word 😁 )
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 was mistaken, it seems is not possible to share variables (outside a .env file, but that would be out of scope for this PR IMO) between mutiple launch.json configurations.
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.
Additionally I currently have no way to test the other configuration on, whether they even still work in their current state, from what I can tell, at least one of them is around 3 years out of date...
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.
Not a different compiler? We just need one (the currently officially supported one)
Or what configurations are you talking about. If they are deprecated the maybe we can remove those?
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.
In launch.json
there are different launch configurations usable via a button in VSCode. These are what I meant.
While I am open to removing them/replacing them with ones that actually work, I would probably like some more input from people who might use them, so maybe in another PR...
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.
Thanks for the clarification. I agree. Let's merge this!
I tried using the devcontainer again, and found a couple snags:
|
Additionally there does not seem to be any source mapping for debugging, I will have to look into that aswell |
Okay, I have now found the correct setting to add source/symbol maps to gdb for debugging. As far as I can tell: |
Indeed. The line endings however is due to git using the local encoding when you check out the repo (ie, in windows, so it gives them CR/LFs) but then when that repo is accessed inside the container all the tools expect unix textfiles. So the actual repo doesn't contain any CR/LF files, they get converted to that when you check them out under windows. We hit this when I was first trying to tackle the whole devcontainers thing. I think this comment provided the best general solution:
Ie, if you do the initial checkout in windows with |
Yikes, thanks windows indeed |
@BloodStainedCrow could you recheck your open points with a |
Both the failed container build and the failed compile are solved with this. The only remaining problem I encountered is the missing source map/ symbol file for debugging. |
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.
Thanks for keep on going, improving and keeping this PR up to date!
No problem, one question before I agree this can be merged:
|
I don't sorry. Let's fix that in a separate PR 😁 |
…1587) * Only use one Dockerfile and build.sh script for both docker and devcontainer * Remove all now unneccessary tasks and scripts * Update to clang-format-14 * Move devcontainer.json into root folder * Fix conditional statements in Dockerfile * Move .devcontainer/README into doc/usingDevcontainers * Remove obsolete VSCode Task * Change standard compiler path to the correct compiler * Set GDB Path for debugging * Hide broken buttons from CMake Extension * Refactor .devcontainer * Remove unneccessary postBuildCommand * Add devcontainer dependencies to all docker images * Add Devcontainer Debug launch config * Add an additional c_cpp_properties config as a fallback for devcontainer * Remove obsolete Docker Argument * Fix wrong C/Cpp versions * Fix silent fail of gdb, add libncurses5
As discussed in #1497 this removes the need for duplicate Dockerfiles for Docker compilation and .devcontainer development. This will reduce variance in compiler environments and make maintenance easier.