-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
-
display-url-api 2.3.4
As a user, I want to override URLs injected by the plugin into environment variables
There is a DisplayURLProvider#getDefault() API which can be used to retrieve the provider extension defined by the user. There is also a DisplayURLProvider#get() which always returns the default provider instance.
The second method is used in https://github.com/jenkinsci/display-url-api-plugin/blob/master/src/main/java/org/jenkinsci/plugins/displayurlapi/EnvironmentContributorImpl.java which contributes environment variables. It means that the provider implementations won't be taken into account.
This is somewaht related to JENKINS-41919, but it is not reported as defect
- causes
-
-
- Closed
-
- is duplicated by
-
JENKINS-41919 System env/property for default implementation not usefull
-
- Closed
-
- relates to
-
-
- Resolved
-
[JENKINS-64119] Display URL Plugin does not consult with DisplayURLProvider implementations when injecting environment variables
Kalle Niemitalo
added a comment - The fix https://github.com/jenkinsci/display-url-api-plugin/pull/42 for this issue caused JENKINS-69006. Please consider reverting that and instead modifying EnvironmentContributorImpl, if this thing is even desirable at all.
Kalle Niemitalo
added a comment - The fix https://github.com/jenkinsci/display-url-api-plugin/pull/42 for this issue caused JENKINS-69006 . Please consider reverting that and instead modifying EnvironmentContributorImpl, if this thing is even desirable at all. Kalle Niemitalo
added a comment - As a user, I want to override URLs injected by the plugin into environment variables
Do you mean a per-user override, or only the controller-wide override configured by an administrator?
If per-user, then suppose user A triggers a run of a job that has been configured (using the Authorize Project plugin) to use the authority of user B. Should the environment variables of the run depend on the preferences of user A or user B?
Why do you want the setting to affect the environment variables at all? If the URLs in the environment variables are constructed by DisplayURLProvider.DisplayURLProviderImpl, then they end with "display/redirect", and each user who opens such a URL in a Web browser is redirected to the UI that corresponds to her or his preferences, or to the default configured by administrators. Except I suppose the per-user preference won't work if the user's Web browser does not have Jenkins login cookies and the Jenkins controller allows anonymous access.
Kalle Niemitalo
added a comment - As a user, I want to override URLs injected by the plugin into environment variables
Do you mean a per-user override, or only the controller-wide override configured by an administrator?
If per-user, then suppose user A triggers a run of a job that has been configured (using the Authorize Project plugin ) to use the authority of user B. Should the environment variables of the run depend on the preferences of user A or user B?
Why do you want the setting to affect the environment variables at all? If the URLs in the environment variables are constructed by DisplayURLProvider.DisplayURLProviderImpl, then they end with "display/redirect", and each user who opens such a URL in a Web browser is redirected to the UI that corresponds to her or his preferences, or to the default configured by administrators. Except I suppose the per-user preference won't work if the user's Web browser does not have Jenkins login cookies and the Jenkins controller allows anonymous access. I agree with kon that this does not really make sense directly. The current behavior is that setting the environment variable or system property effectively bypasses the functionality of the plugin completely.
Fixed long ago in 2.3.4, but I will change the approach shortly to fix JENKINS-69006.
pr ready https://github.com/jenkinsci/display-url-api-plugin/pull/42