Add integration tests

[icetan]

Do we really need a docker container to run the deploy scripts? All dependencies should already be handled by Nix.

Also cloning the latest deploy scripts from within the docker container sort of defeats the purpose of having a docker image in the first place. Shouldn't it run tests on the current source?

[grandizzy]

Do we really need a docker container to run the deploy scripts? All dependencies should already be handled by Nix.

I found it easier to sharing keystore and start parity node locally / make it available to be accessed by dss scripts. I also consider that this image could be built and published and be available for QA tests / automatic deployments (kind of official one with all deps prebuilt)

Also cloning the latest deploy scripts from within the docker container sort of defeats the purpose of having a docker image in the first place. Shouldn't it run tests on the current source?

Yep, that's right, however I couldn't find a cleaner way to map source directory inside docker container due to the out directory that is generated in the same structure (where docker container doesn't have permissions to delete / create it). Hence did the clone workaround

[asymmetric]

@dizzy I think doing this without Docker would be nicer, unless Docker really adds something unique.

It would mean starting parity in Travis, and then running scripts/setup-env.sh.

I also consider that this image could be built and published and be available for QA tests / automatic deployments (kind of official one with all deps prebuilt)

This is kind of achieved already with the shell.nix. It's true that we don't pin parity/geth, but this can be fixed (@icetan wdyt?)

[grandizzy]

@dizzy I think doing this without Docker would be nicer, unless Docker really adds something unique.

It would mean starting parity in Travis, and then running scripts/setup-env.sh.

Yep, OK, will amend PR and do that

[icetan]

This is kind of achieved already with the shell.nix. It's true that we don't pin parity/geth, but this can be fixed (@icetan wdyt?)

Yes, we could definitely pin parity/geth as well. @grandizzy I'll gladly help with this if you want.

I think it would keep things simpler, to be able to run the scripts directly without having to consider breaking docker configs when making script changes.

If we need to create docker images for deploys on QA environments we could actually use Nix to generate those as well. Then we don't have to think about syncing dependencies across several environments and there would be less code to maintain.

Also if we have to consider a QA environment it would be nice to have a defined interface for how to integrate with it.

[asymmetric]

@grandizzy For a quick and dirty solution, you can run parity with nix run nixpkgs.parity. This will use a non-deterministic version, but we can fix that later if/when it becomes an issue.

Let me/@icetan know if instead you need assistance to add a pinned version to the shell.nix.

[gbalabasquer]

What is the status of this PR? Will be continued or can be closed?

[asymmetric]

I'm working on a Docker-less approach here.

[gbalabasquer]

great, so can we close this PR?

[asymmetric]

It's a completely different approach so I would keep it open. If my approach works i'll close this one, as I don't think we strictly need Docker if we can avoid it.