Unable to use global variable in Remote Option URL port number

[gschueler]

Bug report

My Rundeck detail

• Rundeck version: 2.6.11 and 2.7.1
• install type: any
• OS Name/version: any

Expected Behavior

Using global variable in the port number of an option values URL should work.

Actual Behavior

GUI fails to save the change. javascript error:

POST http://ecto1.local:4440/editOpts/save?project=ctest&jobWasScheduled=false 500 (Server Error)
send @ jquery.js?compile=false:8706
ajax @ jquery.js?compile=false:8136
_optsave @ jobedit.js?compile=false:525
onclick @ 280a8afb-5fa9-451d-a2bc-df5852b06cfe:1

Yaml upload fails to validate:

$ rd jobs load -p ctest -f 280a8afb-5fa9-451d-a2bc-df5852b06cfe.yaml --format yaml
Error: Jobs Document was invalid for format yaml: rundeck.controllers.JobXMLException: Unable to create Job: For input string: "${globals.service_port}"
[code: api.error.jobs.import.invalid; APIv18]

How to reproduce Behavior

Set the remote option value URL for an option to something like: http://localhost:${globals.test_port}/path

[puremourning]

Took a brief look at the code.

I guess the issue is that the java.net.URL strictly validates (and requires RFC2396 addresses), and thus validates on construction (attempting to convert the context variable syntax to an int; fails). Other context variables (outside of the port itself) are technically valid RFC2396.

I guess the solution is to use String rather than URL here in Options.groovy and convert to URL when needed (in TBA locations!). This sounds like a chunk of work. Do you think that's the right solution? If so I might pursue it, as this is quite important for my project.

[gschueler]

@puremourning yes i think we need to change to use a string instead of URL to store the value. For grails db update purposes (until we have db-migration set up), it might work to simply change the field to String. If that doesn't work, could add a new String field, and have some logic in the Options class to use that field instead of the URL field.

URL was only used I think for the validation purposes in the first place, so the validation would have to be revamped. The place where the URL is used is only in the code which loads the remote json.

[puremourning]

FYI I have changed this locally (from URL type to String) and it seems to work.

[mumblez]

just to confirm, can I not do something like setting a globals to project.globals.options_server=localhost:5555/options ? would I have to set the port and path separately?

(it seems to urlencode and I get localhost%3A5555%2Foptions)

[puremourning]

you can do this:

project.globals.options_server=localhost:5555

then you can set the option provider to:

valuesUrl: http://${globals.options_server}/options/....

Which is what we ended up doing.

What you can't do is just configure the port in a global.

[mumblez]

@puremourning thanks for the quick response, that works 👍

[puremourning]

you're welcome.

[mcassaniti]

I tried this in a global variable instead and I do have a port configured (i.e.: server:port). I'm finding that the colon gets URL encoded for version 3.2.8 (i.e.: server%3Aport).

[puremourning]

Using global still works for me on rundeck 3.2.8. The only problem with this approach is that if/when the request fails of times out, the URL printed to the UI is url encoded, so you have to manually edit to add the colon if you want to manually run the request to check the output. This is fairly minor.

[mcassaniti]

Ahhh, that might explain something. Let me do a bit more testing and I will confirm. If it does I've suddenly saved a whole bunch of time trying to separate out our TEST and PROD environments.

[mcassaniti]

So I've successfully tested on 3.2.8 and got the expected results. I did hit the failure issue @puremourning mentioned, but I am successfully hitting the URL.

[stale[bot]]

In an effort to focus on bugs and issues that impact currently supported versions of Rundeck, we have elected to notify GitHub issue creators if their issue is classified as stale and close the issue. An issue is identified as stale when there have been no new comments, responses or other activity within the last 12 months. If a closed issue is still present please feel free to open a new Issue against the current version and we will review it. If you are an enterprise customer, please contact your Rundeck Support to assist in your request. Thank you, The Rundeck Team

[stale[bot]]

In an effort to focus on bugs and issues that impact currently supported versions of Rundeck, we have elected to notify GitHub issue creators if their issue is classified as stale and close the issue. An issue is identified as stale when there have been no new comments, responses or other activity within the last 12 months. If a closed issue is still present please feel free to open a new Issue against the current version and we will review it. If you are an enterprise customer, please contact your Rundeck Support to assist in your request. Thank you, The Rundeck Team