Following this recent issue https://github.com/algorand/algorand-sdk-testing/issues/221, each of the SDK's will be using the Sandbox for their algod/kmd/indexer/postgres environment. However, they are still each bringing up a docker container for the SDK themselves.
In principle, the Docker containers for each SDK is unnecessary, and each SDK can be built directly on the CI's VM and communicate directly with the Sandbox containers.
With this in mind, we have a good opportunity to migrate to github actions for the SDK's.
What are you looking for?
Investigate the feasibility of moving off circle to github actions for the SDK's (the biggest question mark for me is the javascript SDK)
Assuming step 1 shows that migrating to G.A. is feasible and advantageous, effect the migration.
Possibly at the same time as step 2, remove the dockerization of each SDK from the build (but maintain the reliance on the Sandbox docker containers)
One downside to this is that it becomes more difficult to run these tests locally for one-off tests. In the past, I have occasionally appreciated being able to run tests without having to set everything up. Or even for small changes, I would do all development through the docker test environment.
With the disclaimer that I haven't fully researched usage, my assumption is these containers are only used in CI builds.
I'm imagining we can speed up the builds by defining an equivalent Github Action (e.g. configures a specific Python version). And we can support local use cases via https://github.com/nektos/act.
Thanks for the clarification. In the past I have used make docker-test in place of setting up a development environment locally. I've also found it useful as a santity check to see if there are issues due to software I have installed compared to the versions used by CI.
It's a good point though, we can probably use standard containers which CI has cached to speed things up.
@tzaffi commented on Wed Aug 17 2022
Context
Currently the SDK's are running their tests on Circle. EG:
Following this recent issue https://github.com/algorand/algorand-sdk-testing/issues/221, each of the SDK's will be using the Sandbox for their algod/kmd/indexer/postgres environment. However, they are still each bringing up a docker container for the SDK themselves.
In principle, the Docker containers for each SDK is unnecessary, and each SDK can be built directly on the CI's VM and communicate directly with the Sandbox containers.
With this in mind, we have a good opportunity to migrate to github actions for the SDK's.
What are you looking for?
Why is it useful? We expect this to:
@winder commented on Wed Aug 17 2022
Does this remove the use of docker entirely?
One downside to this is that it becomes more difficult to run these tests locally for one-off tests. In the past, I have occasionally appreciated being able to run tests without having to set everything up. Or even for small changes, I would do all development through the docker test environment.
@michaeldiamant commented on Wed Aug 17 2022
@winder No, I don't think so. Expanding briefly below though happy to discuss live to go deeper.
@winder commented on Wed Aug 17 2022
Thanks for the clarification. In the past I have used
make docker-test
in place of setting up a development environment locally. I've also found it useful as a santity check to see if there are issues due to software I have installed compared to the versions used by CI.It's a good point though, we can probably use standard containers which CI has cached to speed things up.
Food for thought, maybe worth a live discussion.