Currently, there is a lot of black magic that goes on when draft up is run, spanning at least docker and helm commands.
$ draft up --debug
Draft Up Started: 'my-service': 01CFDW1HQQ5B3ZCGP3YZHFYFPK
my-service: Building Docker Image: SUCCESS ⚓ (1.0038s)
my-service: Pushing Docker Image: SUCCESS ⚓ (2.2107s)
my-service: Releasing Application: FAIL ❌ (1.3373s)
Inspect the logs with `draft logs 01CFDW1HQQ5B3ZCGP3YZHFYFPK`
[debug] No post deploy tasks to run
However, with this issue that is happening on releasing the application, the logs do show a yaml rendering error, but it is relatively hard to debug what might be going on. I believe it would be good if there could be an option to show what helm commands are being run under the hood, so that advanced users can tweak the commands/parameters to assist in the debugging process (for example, by adding --debug or --dry-run flags - although for YAML rendering errors specifically that may not help as much).
I could see something similar for docker commands, but those are relatively less problematic in general, so that could be out of scope for this.
as demonstrated above, passing --debug to the draft up command, which according to the documents might be a reasonable guess to activate this functionality, barely adds any additional information.
Currently, there is a lot of black magic that goes on when
draft up
is run, spanning at leastdocker
andhelm
commands.However, with this issue that is happening on releasing the application, the logs do show a yaml rendering error, but it is relatively hard to debug what might be going on. I believe it would be good if there could be an option to show what
helm
commands are being run under the hood, so that advanced users can tweak the commands/parameters to assist in the debugging process (for example, by adding--debug
or--dry-run
flags - although for YAML rendering errors specifically that may not help as much).I could see something similar for
docker
commands, but those are relatively less problematic in general, so that could be out of scope for this.as demonstrated above, passing
--debug
to thedraft up
command, which according to the documents might be a reasonable guess to activate this functionality, barely adds any additional information.