search

Ensono / independent-runner

MIT License
3 stars 0 forks source link

Pester Unit Tests fail for `Build-DockerImage` when run in Azure DevOps or GitHub Actions #44

Open russellseymour opened 9 months ago

russellseymour commented 9 months ago

Description

There are about 240 Pester tests for the Ensno Independent Runner (EIR). When the module is built, the Docker images for EIR are used to provide isolation and consistency for the build.

The tests are invoked using taskctl:tests, which causes a Docker container to be spun up and Pester invoked. When run on the following platforms, the tests all pass without issue:

However when these same tests are run in Azure DevOps or GitHub actions the 17 tests for Build-DockerImage fail with the following error:

This test should run but it did not. Most likely a setup in some parent block failed.

Investigation

To try and remedy the situation I have stripped back the tests for Build-DockerImage to the bare minimum but I am unable to get the tests to pass in ADO.

As the agens for ADO and GHA are the same, it leas me to believe that there is something going on with the agent that is no present in othe environments that this has been tested on.

Next Steps

Will recreate an agent VHD using Packer and then run it locally to see if it is possble to cause the same error as is being seen.

Although we have set the dry run option so that the commands are not executed, it might be that the docker command is being run (or another command) inadvertently that is causing the error. This will be investigated further.

ElvenSpellmaker commented 2 months ago

This happens locally too now... This needs further investigation

RichardSlater commented 3 weeks ago

I'm only noticing three failed tests on Windows 11 with WSL Ubuntu 24.04, one of them is because of the following:

# Determine the output path based on the OS
if ($isWindows) {
    $output = [IO.Path]::Combine($env:SystemDrive, "output", "tests")
} else {
    $output = [IO.Path]::Combine("/", "output", "tests")
}

Which attempts to write to /output i.e. the root filesystem which with FHS almost guarantees failure without being root. It also calls failures with rootless docker runtimes like Podman. You can work around the issue with:

sudo mkdir /output
sudo chown $USER:$GROUP /output

It's less than ideal though.