Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-10899

Add the ability to show/edit from a job's configuration UI, a properties file containing env vars to be set by envinject

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: envinject-plugin
    • Labels:
      None

      Description

      When env vars to be set by envinject are stored in a properties file, the following problem arises from a job's admin perspective: How is the file viewed/edited? The problem is bigger when the file is not coming from SCM, instead it just sits permanently in some location on the build server, e.g. in the same folder as the job's config.xml

      Feature Request: Add to envinject the ability to show/edit in the job's configuration UI the content of a file containing env vars to be set. If it's possible, show/edit the content inline in the configuration page.

        Activity

        bogdaniosif bogdaniosif created issue -
        Hide
        bogdaniosif bogdaniosif added a comment -

        @gbois can you please comment on this feature request? I would like to make sure that it's clearly formulated since I see that it's the single remaining open issue for envinject.

        I'll state again the need, as succinctly as I can:

        • Define in a single .properties file, env vars to be set by envinject during normal job execution for multiple jobs. Assume we need to store this file on the build server because it stores env vars needed before source control is accessed.
        • PROBLEM: The only way for a build engineer inspecting these jobs' configurations in Jenkins' web UI, to also inspect the content of the .properties file is to use an additional channel; e.g. connect remotely to Jenkins' host and list / edit that .properties file.

        It would be of great help to at least be able to see the content of the .properties file via Jenkins' web UI, in read only mode. It would be fantastic to be able to edit the file via the Jenkins UI.

        Show
        bogdaniosif bogdaniosif added a comment - @gbois can you please comment on this feature request? I would like to make sure that it's clearly formulated since I see that it's the single remaining open issue for envinject. I'll state again the need, as succinctly as I can: Define in a single .properties file, env vars to be set by envinject during normal job execution for multiple jobs. Assume we need to store this file on the build server because it stores env vars needed before source control is accessed. PROBLEM: The only way for a build engineer inspecting these jobs' configurations in Jenkins' web UI, to also inspect the content of the .properties file is to use an additional channel; e.g. connect remotely to Jenkins' host and list / edit that .properties file. It would be of great help to at least be able to see the content of the .properties file via Jenkins' web UI, in read only mode. It would be fantastic to be able to edit the file via the Jenkins UI.
        Hide
        gbois Gregory Boissinot added a comment -

        I'm sorry for getting back to you so late.
        EnvInject plugin is able to inject environment variables for several jobs through 'global properties' section in the 'Manage Jenkins' page.
        I think I understand your use case. However, in my opinion, Jenkins shouldn't have to be in charge of providing mechanisms to display files content.

        With the only usage of EnvInject plugin, you have to store it in a public path accessible though the Jenkins server.
        Howver, the best practice is to store it in a sofware configuration management, especialy environment variables for tracability purposes.
        For this kind of extensibility, you have to look at the SharedObjects plugin. It is a plugin aimed at sharing objects in an environment.
        At the moment, Clearcase is supported.
        Please feel free to add a feature to suport other SCM tools (for the sharedObjects plugin).

        Closing the issue for now and for this component.

        Show
        gbois Gregory Boissinot added a comment - I'm sorry for getting back to you so late. EnvInject plugin is able to inject environment variables for several jobs through 'global properties' section in the 'Manage Jenkins' page. I think I understand your use case. However, in my opinion, Jenkins shouldn't have to be in charge of providing mechanisms to display files content. With the only usage of EnvInject plugin, you have to store it in a public path accessible though the Jenkins server. Howver, the best practice is to store it in a sofware configuration management, especialy environment variables for tracability purposes. For this kind of extensibility, you have to look at the SharedObjects plugin. It is a plugin aimed at sharing objects in an environment. At the moment, Clearcase is supported. Please feel free to add a feature to suport other SCM tools (for the sharedObjects plugin). Closing the issue for now and for this component.
        gbois Gregory Boissinot made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Won't Fix [ 2 ]
        Hide
        bogdaniosif bogdaniosif added a comment -

        The major point you're making is I should store the settings in a file in source control (VCS) and edit it via just like any other source file. My strong counterargument is that I'm not asking this feature for those kind of settings. I'm asking it for settings that do not belong in source control and need to reside in configuration files located on the build server. I think we can agree that such settings exist or otherwise Jenkins would by default suck all its XML files from some sort of VCS instead of storing them on master's file system.

        Think of a job that needs to connect to a custom VCS not supported by a Jenkins plugin. Before a build for this job can retrieve any file from VCS it needs to know connection details to the VCS, settings like a machine name, an URI, a user name, a password, etc. I currently store such settings in a job's SetEnv's config section so that I can see / change them via Jenkins' web ui for job config (I will upgrade to EnvInject eventually anyway but it would be the same thing for the purpose of this example).

        The problem I have is that out of ~60 jobs on my build server, only groups of ~5 jobs use the same set of values for the settings I described above. So I'm stuck with choosing to either write those values in a separate file for each group of jobs and store these files on the build server OR copy/paste those values in each job's SetEnv config section.

        Either way I have to make an uncomfortable trade off. The copy/paste is terrible because it creates redundant information that is hard to maintain. With files I avoid this problem but I make the setting values obscure because they are not visible in a job's config web ui.

        Bottom line is that in this scenario, EnvInject is exactly the same as SetEnv + Envfile and I hoped to get more than the sum of those parts out of EnvInject.

        If you still feel the same way I'll accept your resolution and won't argue about this feature anymore.

        Show
        bogdaniosif bogdaniosif added a comment - The major point you're making is I should store the settings in a file in source control (VCS) and edit it via just like any other source file. My strong counterargument is that I'm not asking this feature for those kind of settings. I'm asking it for settings that do not belong in source control and need to reside in configuration files located on the build server. I think we can agree that such settings exist or otherwise Jenkins would by default suck all its XML files from some sort of VCS instead of storing them on master's file system. Think of a job that needs to connect to a custom VCS not supported by a Jenkins plugin. Before a build for this job can retrieve any file from VCS it needs to know connection details to the VCS, settings like a machine name, an URI, a user name, a password, etc. I currently store such settings in a job's SetEnv's config section so that I can see / change them via Jenkins' web ui for job config (I will upgrade to EnvInject eventually anyway but it would be the same thing for the purpose of this example). The problem I have is that out of ~60 jobs on my build server, only groups of ~5 jobs use the same set of values for the settings I described above. So I'm stuck with choosing to either write those values in a separate file for each group of jobs and store these files on the build server OR copy/paste those values in each job's SetEnv config section. Either way I have to make an uncomfortable trade off. The copy/paste is terrible because it creates redundant information that is hard to maintain. With files I avoid this problem but I make the setting values obscure because they are not visible in a job's config web ui. Bottom line is that in this scenario, EnvInject is exactly the same as SetEnv + Envfile and I hoped to get more than the sum of those parts out of EnvInject. If you still feel the same way I'll accept your resolution and won't argue about this feature anymore.

          People

          • Assignee:
            gbois Gregory Boissinot
            Reporter:
            bogdaniosif bogdaniosif
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: