Skip to content
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 48 commits into from
Jan 8, 2024
Merged

Merge Staging next #49

merged 48 commits into from
Jan 8, 2024

Conversation

deribaucourt
Copy link
Member

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.

deribaucourt and others added 30 commits January 5, 2024 10:44
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 deribaucourt requested review from idillon-sfl and WilsonZiweiWang and removed request for idillon-sfl January 5, 2024 09:47
client/src/driver/BitBakeProjectScanner.ts Dismissed Show dismissed Hide dismissed
Following rebase from staging-next onto staging, this adaptation is
required to make the tests pass again.
@deribaucourt
Copy link
Member Author

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.

Copy link
Member

@idillon-sfl idillon-sfl left a 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

@deribaucourt deribaucourt merged commit 159bf00 into staging Jan 8, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants