-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Conversation
Fix framework casing for case sensitive MacOS builds
Fixed eosiocpp ABI Generation Error
Docker/docker-compose-testnet.yml
Outdated
services: | ||
nodeosd_test: | ||
container_name: nodeosd_test | ||
image: eosio/eos:v1.1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is probably best to either use the latest
tag or actually specify the latest version (v1.2.3
as of right now). This would also apply to the keosd_test container as well.
If the latest
tag is used, the documentation should direct the user to use docker-compose pull
to get the latest version of the image before running docker-compose up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, understood. Curious though, could we backport the older 1.1.x branch with v1.1.0? A lot of testnet docs say you need to start with 1.1.0, then upgrade, so I'm just looking to make it as easy as possible for folks to get up and running with as little changes as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, actually, how about image: eosio/eos:$EOS_TESTNET_VERSION
and then telling the user to set an ENV? That would put the responsibility on the user and not on the eos devs to rememeber to update the value in the file. Life would be much easier :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would feel comfortable using an environmental variable for the testnet docker-compose file. It might also be a good idea to create a .env file with the default value of EOS_TESTNET_VERSION
being set to latest
. This would allow a testnet to be spun up without having to define any environmental variables, while still allowing the tag to be overidden by the environmental variable if it is present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NorseGaud the Jungle testnet has special requirements for v1.1.0 because of an issue they ran into. The mainnet does not have that issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks guys, I'll get the changes into the PR. I believe using .env file is a perfect solution to allow users greater control in an easy way.
- Added genesis file check and inclusion to nodeosd.sh - Use of .env in all .yml so users can control the variables that get used to build - setup.sh scripts for each env - compose.yml for dev - Cleanup of Dockerfiles - Readme improvements
Ok, the final version is committed. I've changed the entire design so that users can just create a copy of the "latest" directory to run multiple eos instances. I've tested "latest" and "dev" setup.sh scripts to confirm they're working. Let me know what you think. |
@ericiles @NorseGaud where are we with this? Looks like there are conflicts now. |
@heifner Just waiting on Eric I believe. |
Hello, can I issue EOS token in eos-dev docker now? |
@jacktang, yep, modify the .env under the dev directory to EOS |
Various Docker improvements: