Test server for linux_arm64 target

[wojked]

I have a M1/M2 Mac and run my apps in docker containers.

When developing in python on my mac directly, tests automatically download the temporal-test-server by hitting this endpoint first:
https://temporal.download/temporal-test-server/default?arch=arm64&platform=darwin&sdk-name=sdk-python&sdk-version=1.2.0

that returns the following content
{"archiveUrl":"https://temporal.download/assets/temporalio/sdk-java/releases/download/v1.17.0/temporal-test-server_1.17.0_macOS_amd64.tar.gz","fileToExtract":"temporal-test-server_1.17.0_macOS_amd64/temporal-test-server"}

I am able to run tests "directly" on my local machine with pytest

But when I try to test my app inside of a docker container that uses linux arm64 it fails because of two reasons:

• RuntimeError: Failed starting test server: Permission denied (os error 13) if just run pytest
• or qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory if I provide pointer to a manually downloaded amd64 binary

This leads me to a quite obvious conclusion, that amd64 test server is not going to run within arm64.

I am unable to run temporal tests in docker on M1/M2 Macs

Describe the solution you'd like
Could you provide builds for linux_arm64 target? This way tests would execute within a dockerised arm64 linux.

Describe alternatives you've considered

• I could use WorkflowEnvironment.start_local() instead of WorkflowEnvironment.start_time_skipping()
• I could skip tests in docker, but is far from perfect.

[wojked]

I am just starting to use temporal and followed the example project:
https://github.com/temporalio/hello-world-project-template-python/blob/main/tests/test_run_worker.py

Right now I am unsure why .start_time_skipping() was used instead of .start_local() in tests.
.start_local() will run temporalite which seems like a good idea, so maybe it should be the way to test.

[cretz]

Duplicate of #1407, but will leave open for a bit in case there are other questions.

[wojked]

Hey @cretz,

I switched into WorkflowEnvironment.start_local() in my tests (instead of WorkflowEnvironment.start_time_skipping()) as I described in the "considered alternatives" without any negative effects (yet).

I hope I will be able to deal with the lack of "automatic time skipping" by placing any "sleeps" in separated activities or individual functions that I will selectively mock in tests so do not see anything blocking me after all (for now).

Thank you for leaving it open, I feel we might close it as duplicate, but let's wait, maybe there are questions from other people too.

[mjameswh]

There no longer seems to be any reason to keep this one open.

Closing as duplicate of #1407.