Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test server for linux_arm64 target #1783

Closed
wojked opened this issue Jun 9, 2023 · 4 comments
Closed

Test server for linux_arm64 target #1783

wojked opened this issue Jun 9, 2023 · 4 comments
Labels
enhancement User experience

Comments

@wojked
Copy link

wojked commented Jun 9, 2023

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 wojked added the enhancement User experience label Jun 9, 2023
@wojked
Copy link
Author

wojked commented Jun 9, 2023

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
Copy link
Member

cretz commented Jun 9, 2023

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

@wojked
Copy link
Author

wojked commented Jun 14, 2023

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
Copy link
Contributor

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

Closing as duplicate of #1407.

@mjameswh mjameswh closed this as not planned Won't fix, can't repro, duplicate, stale Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement User experience
Projects
None yet
Development

No branches or pull requests

3 participants