-
Notifications
You must be signed in to change notification settings - Fork 11
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
Merge Staging next #49
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use `devtool status` to get the list of devtool workspaces.
Preparing for new devtool commands, improve clarity or genericity of some presented UI elements.
Present the scan results for devtool workspaces in a new view that will allow manipulating them.
Add commands to modify, update, reset and open devtool workspaces.
There is no necessity for a singleton here. It makes the code harder to test.
With kas-container or custom docker mount-points, the devtool-open-workspace command would fail to try to open the container's workspace path on the host system. Add the required logic to resolve the path to the host system. It's a bit tricky if the container's mount points are different between the sources and the build workspaces. We only support trivial cases for now which work with kas-container.
When using the devtool-update-recipe command in a container, the paths have to be resolved between host and container.
Settings change will provoke a rescan command. If it hasn't been called since the last sanity check, it doesn't need to be checked again. This noticeably speeds up the on save parsing and devtool modify command.
Some tests only bother with providing recipes. Consider a scanResult to be valid if it contains either layers or recipes.
If bitbake sanity tests or parsing is stuck for some reason (buggy commandWrapper, filesystem issues, CPU load...), the extension freatures would get frozen.
Define the general timeout for running a bitbake parsing command as a constant. This will allow us to change the timeout in a single place. Note that this is not for regular bitbake builds which can take hours.
Sending bitbake when a terminal is closed may not be enough to kill it as it may take minutes before started tasks finish. Sending a second and third signal after a timeout ensures bitbake is stopped before a minute. Note that this does not work for docker containers yet: https://stackoverflow.com/a/50034061/20690788
New eslint extension updated it's settings.
Bitbake requires multiple SIGINT signals to fully stop when stuck. Additionally, docker container processes are not properly killed by calling child.kill() on the shell process. We instead find the process PID and kill it directly.
The user will want to see the results of devtool modify/reset in the devtool workspaces view as soon as the command completes. Add a brief rescan of the devtool workspaces to the command handlers.
Fixes the following bugs: - Starting multiple bitbake processes at the same time would not open new terminals - Stopping a bitbake process that has not started yet would let it execute
If multiple commands where started at the same time, and we closed a terminal that was still waiting for the bitbake lock, it could have been reused.
This command allows to configure a devtool workspace for cross-compilation and debugging.
We don't provide a "Don't show again" option for this error, as it can only be started by explicit manual user action.
The SSH target configuration is now a single string instead of an object. We'll rely on the user's SSH configuration file to define additional options. devtool has other configs, but we may define them later if needed with a separate bitbake.sshOptions settings object
The new parameter for bitbake tasks will allow running devtool eSDK commands from external workspaces for application developpers. I would have preferred not exposing the use of such custom commands but writing the command assembly logic seems overkill here. The documentation states that this configuration is intended for internal use by the extension.
This command will allow users who don't have the `devtool ide-sdk` poky command, or use recipe classes which are not yet supported. The generated tasks.json will use `devtool build` and `devtool deploy-target` instead of `devtool ide-sdk`. This will be slower, and not provide advanced features such as debugging and linting, but will still allow users to build and deploy their recipes.
Our Jest tests usually take 2-3minutes so they timed out through the jest extension watcher.
This allows users to identify spawn errors because the workingDirectory is not set correctly.
This mode will disable the features using bitbake, but keep the devtool features enabled.
bitbake won't be available in eSDK mode. Disable some related features.
In eSDK mode, we don't have access to the full bitbake environment, but some features can still be useful with some adaptations.
Even though bitbake is available in these workspace's configurations, we don't want to do a bitbake scan and have bitbake features enabled.
The devtool build/clean commands replace bitbake in the case we are using an eSDK.
deribaucourt
requested review from
idillon-sfl and
WilsonZiweiWang
and removed request for
idillon-sfl
January 5, 2024 09:47
Following rebase from staging-next onto staging, this adaptation is required to make the tests pass again.
There's only code that's already been approved and merged to staging next. Just tell me if you don't agree with the idea. |
idillon-sfl
approved these changes
Jan 6, 2024
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.
Sounds good to me
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Devtool functionalities and especially scanning optimizations should be part of the next release. I rebased staging-next and want to merge it into staging for the incoming release.