search

microsoft / VSTS-Docker-Preview

Preview repo for Docker extension
16 stars 8 forks source link

docker-compose.exe failed with return code: 4294967295 #8

Closed offbeatful closed 7 years ago

offbeatful commented 7 years ago

docker-compose was working previously for version 0.1.12. Starting from version 0.2.0 (which was deployed about 23 hours ago) it stoped working with the following error:

docker-compose.exe -H tcp://XX.XX.XX.XXX:2376/ --tls --tlscacert='.dockercerts\ca.pem' --tlscert='.dockercerts\cert.pem' --tlskey='.dockercerts\key.pem' -f D:/_work/13f36174b/project/scripts/docker-compose.yml -f .docker-compose.1476451184894.yml -p website up -d Traceback (most recent call last): File "", line 3, in File "compose\cli\main.py", line 62, in main File "compose\cli\main.py", line 111, in perform_command File "compose\cli\command.py", line 34, in project_from_options File "compose\cli\docker_client.py", line 39, in tls_config_from_options File "site-packages\docker\tls.py", line 47, in init docker.errors.TLSParameterError: Path to a certificate and key files must be provided through the client_config param. TLS configurations should map the Docker CLI client configurations. See https://docs.docker.com/engine/articles/https/ for API details. docker-compose returned -1

Please advice.

Update: it does not work for version 0.2.1 as well.

stepro commented 7 years ago

@offbeatful , sorry for the trouble you are having. There was a major rewrite of the extension for version 0.2.0 and along the way, an incorrect assumption was made about how host information can be specified for the docker-compose CLI (the official Docker documentation is incorrect). We have revalidated all custom host connection scenarios for both the Docker and Docker Compose tasks and pushed a new version, 0.2.3 which your accounts should automatically pick up.

Please let us know if you are still seeing issues.

offbeatful commented 7 years ago

It took some time to adjust build process. There are new settings added and by some reason they were active by default (additional tags for images). All in all deployment works fine now. You may close this issue. Thanks!

stepro commented 7 years ago

Yes, there were some new options added in 0.2.0 such as additional tags for images. The goal was to maintain backward compatibility for existing instances of the tasks while also supplying appropriate defaults for new options when creating new instances of the tasks. We believe that it is common and useful to build and push the same image with multiple tags as this makes the images more easily consumable from the repository. Please do let us know if you think the defaults are inappropriate, or you considered this a breaking change and the whole additional tag concept should only be enabled if some other Boolean option is checked. Thanks!

offbeatful commented 7 years ago

@stepro thanks for having time to discuss this. New options were useful for us but their defaults were not. Typically what we want is to build an image and then tag this image with version tag and latest tag. First option allow us to maintain CI process consistent and latest tag will allow us to spin the most latest version from our repository. We don't need any other tags. It would be better if Additional Image Tags and Include Source Tags were cleared by default.

stepro commented 7 years ago

I am just about to push a new version that clears these defaults so that behavior of the 0.2.x tasks are precisely the same as the behavior of the <0.2 tasks.

stepro commented 7 years ago

The update has been pushed.

offbeatful commented 7 years ago

@stepro Thanks! That is awesome!