Skip to content

Commit

Permalink
docs: update notes on interactive debugging
Browse files Browse the repository at this point in the history
Signed-off-by: AtomicFS <vojtech.vesely@9elements.com>
  • Loading branch information
AtomicFS committed Jan 24, 2025
1 parent b55ce04 commit f1960ae
Show file tree
Hide file tree
Showing 4 changed files with 39 additions and 21 deletions.
2 changes: 1 addition & 1 deletion cmd/firmware-action/main.go
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ var CLI struct {
Build struct {
Target string `required:"" help:"Select which target to build, use ID from configuration file"`
Recursive bool `help:"Build recursively with all dependencies and payloads"`
} `cmd:"build" help:"Build a target defined in configuration file"`
} `cmd:"build" help:"Build a target defined in configuration file. For interactive debugging preface the command with 'dagger run --interactive', for example 'dagger run --interactive $(which firmware-action) build --config=...'. To install dagger follow instructions at https://dagger.io/"`

GenerateConfig struct{} `cmd:"generate-config" help:"Generate empty configuration file"`
Version struct{} `cmd:"version" help:"Print version and exit"`
Expand Down
2 changes: 1 addition & 1 deletion docs/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@
- [Get firmware-action](firmware-action/get_started/04_get_firmware_action.md)
- [Run firmware-action locally](firmware-action/get_started/05_run_firmware_action.md)
- [Run firmware-action in CI](firmware-action/get_started/06_run_in_ci.md)
- [Interactive mode](firmware-action/interactive.md)
- [Interactive debugging](firmware-action/interactive.md)
- [TLDR; Usage](firmware-action/usage.md)
- [Local system](firmware-action/usage_local.md)
- [GitHub CI](firmware-action/usage_github.md)
Expand Down
2 changes: 1 addition & 1 deletion docs/src/firmware-action/get_started/get_started.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,5 +15,5 @@ The code from this example is available in [firmware-action-example](https://git

- installed [Docker](https://wiki.archlinux.org/title/Docker)
- installed git
- installed [dagger](https://docs.dagger.io/install) (optional, needed for interactive debugging)
- installed [taskfile](https://taskfile.dev/) (optional)

54 changes: 36 additions & 18 deletions docs/src/firmware-action/interactive.md
Original file line number Diff line number Diff line change
@@ -1,35 +1,53 @@
# Interactive mode
# Interactive debugging

```admonish note title="A little bit of backstory"
While I was playing around with firmware-action I found early on that debugging what is going on inside the docker container is rather lengthy and annoying process. This was the moment when the idea of some interactive option was born.
While I was playing around with `firmware-action` I found early on that debugging what is going on inside the docker container is rather lengthy and annoying process. This was the moment when the idea of some interactive option was born.
```

```admonish bug title="Issue [#269](https://github.com/9elements/firmware-action/issues/269)"
```admonish done collapsible=true title="Dropping the SSH feature in favor of Dagger build-in debugging"
Dagger [since v0.12](https://dagger.io/blog/dagger-0-12) supports new built-in interactive debugging.
We are already planning to re-write `firmware-action` to use this new feature instead of the `ssh` solution we are currently using. For more details see issue [269](https://github.com/9elements/firmware-action/issues/269).
```
~~We are already planning to re-write `firmware-action` to use this new feature instead of the `ssh` solution we are currently using. For more details see issue [269](https://github.com/9elements/firmware-action/issues/269).~~
**UPDATE:** It is possible now to use the new and shiny feature of dagger for interactive debugging! As a result we have dropped the SSH feature.
On build failure open `ssh` server in the container and let user connect into it to debug the problem. To enable this feature user has to pass argument `--interactive`. User can ssh into the container with a randomly generated password.
Related:
- Issue [#269](https://github.com/9elements/firmware-action/issues/269)
- Pull Request [#522](https://github.com/9elements/firmware-action/pull/522)
The container will keep running until user presses `ENTER` key in the terminal with firmware-action running.
Supplementary dagger documentation:
- Blog post [Dagger 0.12: interactive debugging](https://dagger.io/blog/dagger-0-12)
- Documentation for [Interactive Debugging](https://docs.dagger.io/features/debugging)
- Documentation for [Custom applications](https://docs.dagger.io/api/sdk/#custom-applications)
- Documentation for [Interactive Terminal](https://docs.dagger.io/api/terminal/)
```

To leverage the use of interactive debugging, you have to install [dagger CLI](https://docs.dagger.io/install).

```admonish attention
The container is launched in the interactive mode before the failed command was started.
Then when using `firmware-action`, simply prepend the command with `dagger run --interactive`.

This reverting behavior is out of technical necessity.
Instead of:
```bash
firmware-action build --config=firmware-action.json --target=coreboot-example
```
Execute this:
```bash
dagger run --interactive firmware-action build --config=firmware-action.json --target=coreboot-example
```

```admonish note
The containers in dagger (at the time of writing) are single-use non-interactive containers. Dagger has a pipeline (command queue for each container) which starts executing only when specific functions such as [Sync()](https://pkg.go.dev/dagger.io/dagger#Container.Sync) are called which trigger evaluation of the pipeline inside the container.
To start a `ssh` service and wait for user to log-in, the container has to be converted into a [service](https://pkg.go.dev/dagger.io/dagger#Container.AsService) which also forces evaluation of the pipeline. And if any of the commands should fail, it would fail to start the `service` container.
If you are using `Taskfile` to abstract away some of the complexity that comes with larger projects, simply prepend the whole `Taskfile` command.

As a workaround, when the evaluation of pipeline fails in the container, the container from previous step is converted into a `service` container with everything as it was just before the failing command was executed. In essence, when you connect, you end up in pristine environment.
Instead of:
```bash
task build:coreboot-example
```

~~~go
{{#include ../../../cmd/firmware-action/container/ssh.go:ContainerAsService}}
~~~
Execute this:
```bash
dagger run --interactive task build:coreboot-example
```


On build failure you will be dropped into the container and can debug the problem.

To exit the container run command `exit` or press `CTRL+D`.

0 comments on commit f1960ae

Please sign in to comment.