Issues with implementation of Buildah and Nerdctl SAL #21

New Issue

maximevanhees · 2025-07-02T15:08:06Z

maximevanhees commented

2025-07-02 15:08:06 +00:00

Upon investigation it seems that the following tests were not executing correctly and/or giving false positives:

rhai_tests/buildah/01_builder_pattern.rhai
rhai_tests/buildah/02_image_operations.rhai
rhai_tests/buildah/03_container_operations.rhai
rhai_tests/buildah/run_all_tests.rhai

Each of these files uses has a is_buildah_available function at the beginning of the script to check for the presence of the buildah executable. As this function is inherently broken, none of the tests were able to get executed.

fn is_buildah_available() {
    try {
        let result = run("which buildah");
        return result.success;
    } catch(err) {
        return false;
    }
}

The run function gets registered to the engine upon the execution the of a test script using herodo. The run function is part of the process module, which gets registered when creating the engine (which gets done by herodo when executing a .rhai-script). The function itself only creates a RhaiCommandBuilder instance (registered as a CommandBuilder with the engine), but does not yet execute the command. For that, an additional .execute() call is required.

fn is_buildah_available() {
    try {
        let command = run("which buildah");
        let result = command.execute();
        return result.success;
    } catch(err) {
        return false;
    }
}

Fixing this (simple) bug lead to a chain of failing tests, which should -IMO- get fixed before continuing with #20.

Upon investigation it seems that the following tests were not executing correctly and/or giving false positives: - `rhai_tests/buildah/01_builder_pattern.rhai` - `rhai_tests/buildah/02_image_operations.rhai` - `rhai_tests/buildah/03_container_operations.rhai` - `rhai_tests/buildah/run_all_tests.rhai` Each of these files uses has a `is_buildah_available` function at the beginning of the script to check for the presence of the `buildah` executable. As this function is inherently broken, none of the tests were able to get executed. ```rhai fn is_buildah_available() { try { let result = run("which buildah"); return result.success; } catch(err) { return false; } } ``` The `run` function gets registered to the engine upon the execution the of a test script using `herodo`. The `run` function is part of the `process` module, which gets registered when creating the engine (which gets done by `herodo` when executing a `.rhai`-script). The function itself only creates a `RhaiCommandBuilder` instance (registered as a `CommandBuilder` with the engine), but does not yet execute the command. For that, an additional `.execute()` call is required. ```rhai fn is_buildah_available() { try { let command = run("which buildah"); let result = command.execute(); return result.success; } catch(err) { return false; } } ``` Fixing this (simple) bug lead to a chain of failing tests, which should -IMO- get fixed before continuing with https://git.ourworld.tf/herocode/sal/issues/20.

maximevanhees changed title from ~~Issues with running the `buildah` tests~~ to Issues with implementation of Buildah and Nerdctl SAL

2025-07-10 12:22:35 +00:00

maximevanhees commented

2025-07-10 12:43:05 +00:00

Due to multiple issues with the existing SAL modules for Buildah and Nerdctl, an extensive refactoring of the code is needed (WIP). For this I have created a new branch development_containers.

Some of the main issues/bugs encountered are:

Failing tests for buildah and nerdctl: functions used in test scripts were not registered with the Rhai scripting engine or were simply non-existent.
Usage of keywords which are not defined in the Rhai scripting language.
Logic errors in both the buildah and nerdctl modules
Incorrect usage of getters/setters; not following the builder-pattern which the Rhai scripting language recommends.
...

It looked like most of the tests written for these SAL modules were not properly executed before being committed.

Due to multiple issues with the existing SAL modules for `Buildah` and `Nerdctl`, an extensive refactoring of the code is needed (WIP). For this I have created a new branch `development_containers`. Some of the main issues/bugs encountered are: - Failing tests for `buildah` and `nerdctl`: functions used in test scripts were not registered with the Rhai scripting engine or were simply non-existent. - Usage of keywords which are not defined in the Rhai scripting language. - Logic errors in both the `buildah` and `nerdctl` modules - Incorrect usage of getters/setters; not following the builder-pattern which the Rhai scripting language recommends. - ... It looked like most of the tests written for these SAL modules were not properly executed before being committed.

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: herocode/sal#21