linuxdeployqt -g guesses wrong at times

[probonopd]

-g is supposed to check TRAVIS_TAG and if it is empty or "continuous", then it should set the update information to "continous"; in all other cases to "latest".

According to https://docs.travis-ci.com/user/environment-variables/

TRAVIS_TAG: If the current build is for a git tag, this variable is set to the tag’s name.

So why is it that we get

Guessing update information based on $TRAVIS_TAG=(null)

https://travis-ci.org/AppImage/NCSA-Mosaic-AppImage/builds/297852566#L5379
but

Guessing update information based on $TRAVIS_TAG=[secure]

in https://travis-ci.org/Subsurface-divelog/subsurface/builds/298113422#L7050?

And why would Travis CI even replace the value of $TRAVIS_TAG with [secure]?

As a result, we get

me@host:~$ /home/me/Downloads/Subsurface-988d5bc-x86_64.AppImage --appimage-updateinformation
gh-releases-zsync|Subsurface-divelog|subsurface|latest|Subsurface-_*-x86_64.AppImage.zsync

where latest is wrong and should be continuous.

[TheAssassin]

And why would Travis CI even replace the value of $TRAVIS_TAG with [secure]?

The docs describe it like so:

TRAVIS_TAG: If the current build is for a git tag, this variable is set to the tag’s name.

So yes, should probably be empty (or (null), actually). Probably an issue in Subsurface's Travis CI configuration.

[dirkhh]

Any idea what might be set up incorrectly? I haven't done anything that I'm aware of to mess with the Travis environment variables...

[probonopd]

I can't see anything strange in your .travis.yml. Can you throw in an echo "TRAVIS_TAG: $TRAVIS_TAG" please?

[TheAssassin]

Well, Travis CI has that feature that the values of environment variables are hidden in the logs.
So this might be just a log formatting thing, [secure] might not be the real value.

[dirkhh]

BTW - i asked you about this elsewhere... why don't I see the result of the updatetool in the build log?
Where would you like me to add the echo $TRAVIS_TAG ?

[dirkhh]

@TheAssassin do I need to somehow explicitly enable that variable?

[TheAssassin]

No, it's one of the variables Travis CI creates.

About uploadtool (it's not updatetool, so maybe a in-browser search might not have worked because of that), see e.g., https://travis-ci.org/Subsurface-divelog/subsurface/builds/298113422#L7156.
Travis' after_success section's commands are collapsed by default, you'll have to hit the little triangle on the left side.

Travis CI provides a switch in the job settings in their web interface where you can un-hide the values. However, I wouldn't recommend it, since the more confidential values are then exposed, too.

[probonopd]

Well, Travis CI has that feature that the values of environment variables are hidden in the logs.
So this might be just a log formatting thing, [secure] might not be the real value.

Variables that are entered as "secure variables" in the Travis CI UI are supposed not to show up in the build logs and are hence censored with [secure]. What I don't understand is why Travis CI thinks $TRAVIS_TAG is a secure variable, and censors its content.

@dirkhh could it be, by pure chance, that you have configured a "secure variable" in the Travis CI UI with the name TRAVIS_TAG, or one with an empty value or a value of continuous? Just speculating wildly here.

[TheAssassin]

@probonopd you either switch it on or off, I don't remember a blacklist feature. But yes, that might be a Travis bug.

[probonopd]

See that "Display value in build log" there? Maybe it is somehow related to that. But beware, do NOT inadvertently show you private stuff like encryption keys, API keys, etc. in the build logs!

[probonopd]

Btw, @dirkhh it's not clear at all whether the bug has to do with anything in your repository or Travis CI setup at all. This feature is really very fresh, may well be our bug.

[dirkhh]

OK, thanks for the hint with the build log @TheAssassin
@probonopd - I don't have any environment variables except for the GITHUB_TOKEN

[TheAssassin]

@dirkhh to make sure it's not an issue with the settings on Travis, we're running a build for a repository fork at the moment. We'll report back as soon as possible.