SQL Server initialization issue with Integration tests

[enrico23]

Hi everyone 🙂
I wanted to understand how to run integration/functional tests using Aspire on my CI/CD pipeline using GitHub workflows.
I have only two simple tests. The first is based on https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/testing and it works.
The second one calls an endpoint on the SUT that relies on the connection to a SQL Server database instance. When the test runs the SQL Server instance should be already up and a database created.
In my first attempt, I have based the database initialization strategy on the following Aspire Sample: https://github.com/dotnet/aspire-samples/tree/main/samples/DatabaseContainers.

My configuration is the following:

var db = builder.AddSqlServer("sqlserver")
    .WithBindMount("./sqlserverconfig", "/usr/config")
    .WithBindMount("../DatabaseContainers.ApiService/data/sqlserver", "/docker-entrypoint-initdb.d")
    .WithEntrypoint("/usr/config/entrypoint.sh")
    .AddDatabase("AddressBook");

The problem with permissions for /usr/config/entrypoint.sh . It should be executable, but it isn't.
I get the following error:

 container has failed to start	{"Container": {"name":"sql_1ec953ba"}, "Reconciliation": 11, "error": "StartContainers command returned error code 1 Stdout: '' Stderr: 'Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: \"/usr/config/entrypoint.sh\": permission denied: unknown\nError: failed to start containers: 8f3ecdb1c54854d2bd982adcd67fb735aba8fdd1a7c3aa46f5abce7a03dcb3b2\n'"}

I have tried to run migrations before to run the tests using the following documentation: https://learn.microsoft.com/en-us/dotnet/aspire/database/ef-core-migrations, but I get concurrency issues instead.

Do you have any suggestions?

Thanks in advance 🙂

[enrico23]

This issue probably requires more investigation and time than what is allocated for a POC 🙂

I changed my approach and made the test project responsible for ensuring the database was available before running the tests by introducing a delay.

It would be great anyway to be able to run initialization scripts when the container starts up, but it won't solve the issue of having the SQL Server instance ready before the test run.