Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gomplate fails with no error message #1013

Closed
Plyshak opened this issue Dec 22, 2020 · 5 comments
Closed

Gomplate fails with no error message #1013

Plyshak opened this issue Dec 22, 2020 · 5 comments
Assignees

Comments

@Plyshak
Copy link

Plyshak commented Dec 22, 2020

Hi, we are using gomplate in our system and discover the fact, that once in like 20 runs, it fails without any error message.

Gomplate is called like this:

    echo "  > ${app_mutation} @ ${env_name} ..."
    ENV_NAME="${env_name}" \
    APP_MUTATION="${app_mutation}" \
    GOMPLATE_SUPPRESS_EMPTY=true \
    gomplate \
        "${datasources[@]}" \
        --file "${template_file}" \
        --out "${dest_dir}/${env_name}.${app_mutation}.env" \
        --verbose
    echo "  > ${app_mutation} @ ${env_name} done"

But even with --verbose flag we dont have any usefull info, the output looks like this:

> currys @ local ...
{"level":"debug","time":"2020-12-14T13:33:51Z","message":"starting gomplate"}
{"level":"debug","version":"3.7.0","build":"ed380bef","time":"2020-12-14T13:33:51Z","message":"config is:\n---\ninputFiles: [/data-source/config-template.tpl]\noutputFiles: [/data-target/3_target/local.currys.env]\nsuppressEmpty: true\nleftDelim: '{{'\nrightDelim: '}}'\ndatasources:\n  checkout:\n    url: file:///data-target/2_pregenerated/checkout.yml\n    header: {}\n  common:\n    url: file:///data-target/2_pregenerated/common.yml\n    header: {}\n  creation:\n    url: file:///data-target/2_pregenerated/creation.yml\n    header: {}\n  delivery_slot_matrix:\n    url: file:///data-target/2_pregenerated/delivery_slot_matrix.yml\n    header: {}\n  ecrebo:\n    url: file:///data-target/2_pregenerated/ecrebo.yml\n    header: {}\n  fo_site:\n    url: file:///data-target/2_pregenerated/fo_site.yml\n    header: {}\n  infra:\n    url: file:///data-target/2_pregenerated/infra.yml\n    header: {}\n  world_pay:\n    url: file:///data-target/2_pregenerated/world_pay.yml\n    header: {}\npluginTimeout: 5s\n"}
{"level":"debug","data":"&{Sources:map[checkout:checkout=file:///data-target/2_pregenerated/checkout.yml () common:common=file:///data-target/2_pregenerated/common.yml () creation:creation=file:///data-target/2_pregenerated/creation.yml () delivery_slot_matrix:delivery_slot_matrix=file:///data-target/2_pregenerated/delivery_slot_matrix.yml () ecrebo:ecrebo=file:///data-target/2_pregenerated/ecrebo.yml () fo_site:fo_site=file:///data-target/2_pregenerated/fo_site.yml () infra:infra=file:///data-target/2_pregenerated/infra.yml () world_pay:world_pay=file:///data-target/2_pregenerated/world_pay.yml ()] sourceReaders:map[] cache:map[] extraHeaders:map[]}","time":"2020-12-14T13:33:51Z","message":"created data from config"}
> currys @ local done
> currys @ infra ...
> All done

Any thoughts how to discover the real problem?

@hairyhenderson
Copy link
Owner

Hi @Plyshak, thanks for logging this.

Are you using the slim variant of gomplate? If so, you may want to try the regular one.

If you're not sure, one easy way to tell is by looking at the file size of the binary - if it's under 10MB it's the slim one. There have been a few reports of intermittent failures with the slim binaries, due to some bugs in UPX (which is used to compress the slim binaries).

I also see that you're using v3.7.0, which is not the latest. You could try v3.8.0, which fixes a few bugs that were in v3.7.0.

Hope that helps! Please let me know if either of these options work for you!

@hairyhenderson hairyhenderson self-assigned this Dec 22, 2020
@Plyshak
Copy link
Author

Plyshak commented Dec 23, 2020

Hi @hairyhenderson, thank You very much for quick response.

We are using alpine version. but as You suggest I update our version to latest (3.8.0-alpine) and after few hours of testing, it looks solid and no more failing. If there will be any other issue, I will write back.

Thanks!

@hairyhenderson
Copy link
Owner

@Plyshak ah - yeah, that sounds like the UPX-related slim issues. The alpine Docker image still uses the slim binary, though I want to change that to the uncompressed one (see #1007)

@Plyshak
Copy link
Author

Plyshak commented Dec 23, 2020

@hairyhenderson unfortunatelly I can`t decide this change on my own, but I will raise it as a possible solution, if another error will come to our way. Again, thank you very much for your help! With regards :) Tomas

@hairyhenderson
Copy link
Owner

Understood! Since the 3.8 upgrade seems to be helping, I'm going to close this issue. If you have more trouble, feel free to re-open and continue the conversation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants