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

"Run the build in a RVM-managed environment" field gets unchecked after restarting the Jenkins server.

      Environment:
      1 jenkins server with multiple slaves
      all jobs affected by this are executed by the same slave.
      All the jobs that have been configured to use the plugin and use the "Run the build in a RVM-managed environment" option, after restarting the jenkins, lose this setting.
      The "Run the build in a RVM-managed environment" check box is unchecked after server restart.

      using RVM plugin 0.6

          [JENKINS-37771] "Run the build in a RVM-managed environment" field gets unchecked after restarting the Jenkins server.

          Menahem Vardi added a comment -

          Hi mgreco2k,

          I will try to downgrade ruby runtime plugin.

          Thank you for your help,
          Menahem

          Menahem Vardi added a comment - Hi mgreco2k , I will try to downgrade ruby runtime plugin. Thank you for your help, Menahem

          Norman Klehr added a comment -

          I was facing the same issue but with the RBENV plugin. I configured it for a job in the 'Build Environment' section to use Ruby version 2.2.4. Every time Jenkins service gets restarted or server rebooted it was dropping this configuration on the job level. Strange thing was also when I checked the config.xml file for this job it still looked the same and timestamp of that file didnt even change. Is there a cache Jenkins keeping that information before fetching from config.xml again?

          Anyway downgrading the Ruby-Runtime-Plugin from 0.13 to 0.12 helped in my case as well.

          I would like to know what the difference is between these versions but doesnt seem to be under github?!

          Norman Klehr added a comment - I was facing the same issue but with the RBENV plugin. I configured it for a job in the 'Build Environment' section to use Ruby version 2.2.4. Every time Jenkins service gets restarted or server rebooted it was dropping this configuration on the job level. Strange thing was also when I checked the config.xml file for this job it still looked the same and timestamp of that file didnt even change. Is there a cache Jenkins keeping that information before fetching from config.xml again? Anyway downgrading the Ruby-Runtime-Plugin from 0.13 to 0.12 helped in my case as well. I would like to know what the difference is between these versions but doesnt seem to be under github?!

          Mike Caspar added a comment -

          I don't know if it helps or hinders, but this Seems to be related (or similar) to this old issue...

          https://issues.jenkins-ci.org/browse/JENKINS-38145

          Hope it helps.

          Mike Caspar added a comment - I don't know if it helps or hinders, but this Seems to be related (or similar) to this old issue... https://issues.jenkins-ci.org/browse/JENKINS-38145 Hope it helps.

          Jonathan Strickland added a comment - - edited

          Wish my team had read this thread before we did an upgrade. We found 1 current workaround is to "reload configuration" after the reboot. For some reason, this will enables the build environment configuration.

          As noted above, downgrade from 0.13 -> 0.12 fixes the issue.

          Jonathan Strickland added a comment - - edited Wish my team had read this thread before we did an upgrade. We found 1 current workaround is to "reload configuration" after the reboot. For some reason, this will enables the build environment configuration. As noted above, downgrade from 0.13 -> 0.12 fixes the issue.

          JP Duffy added a comment -

          For me nothing in Build Environment sticks. I use Color ANSI, RVM, and SSH Agent and have to reset these at least once a day. On all my jobs...

          The Reload Configuration trick mentioned above doesn't work for me.

          Jenkins 2.19.2
          ruby-runtime 0.13
          rvm 0.6
          AnsiColor 0.4.2
          SSH Agent 1.13
          Ubuntu 14.04LTS

          JP Duffy added a comment - For me nothing in Build Environment sticks. I use Color ANSI, RVM, and SSH Agent and have to reset these at least once a day. On all my jobs... The Reload Configuration trick mentioned above doesn't work for me. Jenkins 2.19.2 ruby-runtime 0.13 rvm 0.6 AnsiColor 0.4.2 SSH Agent 1.13 Ubuntu 14.04LTS

          Our team is encountering the same issue. Our build machine is a mac mini running Jenkins 2.35. On each machine restart or jenkins restart, all Build Environment options are cleared. This includes Delete workspace, setting the Ruby environment using RVM or rbenv, and all Android emulator options. We have over a dozen jobs and are creating more daily; it is painful to go back and update these on each restart.

          Note: I rolled back to ruby-runtime 0.12 and did not see any improvements.

          Matthew Hessing added a comment - Our team is encountering the same issue. Our build machine is a mac mini running Jenkins 2.35. On each machine restart or jenkins restart, all Build Environment options are cleared. This includes Delete workspace, setting the Ruby environment using RVM or rbenv, and all Android emulator options. We have over a dozen jobs and are creating more daily; it is painful to go back and update these on each restart. Note: I rolled back to ruby-runtime 0.12 and did not see any improvements.

          Dave Hildebrandt added a comment - related: https://issues.jenkins-ci.org/browse/JENKINS-37353

          Dave Hildebrandt added a comment - - edited

          I have gone as far as to create an hourly job that commits changes to config.xml files in my jobs dir if they are updated. Later, jenkins crashed and the config.xml files were modified as noted earlier in this bug. I used git to revert the change and reloaded from config in two different ways:

          • I recovered the correct content using git with the server shut down, and when I started it up, the jobs did NOT have the config AND the config files had been modified to remove the correct settings.
          • I recovered the correct content using git with the server running, hit "reload config from disk" and after that completed, the jobs did NOT have the correct config. The config files were NOT modified in this case.

          Dave Hildebrandt added a comment - - edited I have gone as far as to create an hourly job that commits changes to config.xml files in my jobs dir if they are updated. Later, jenkins crashed and the config.xml files were modified as noted earlier in this bug. I used git to revert the change and reloaded from config in two different ways: I recovered the correct content using git with the server shut down, and when I started it up, the jobs did NOT have the config AND the config files had been modified to remove the correct settings. I recovered the correct content using git with the server running, hit "reload config from disk" and after that completed, the jobs did NOT have the correct config. The config files were NOT modified in this case.

          Code changed in jenkins
          User: Daniel Spilker
          Path:
          src/main/resources/artifact-ignores.properties
          http://jenkins-ci.org/commit/backend-update-center2/803812c3149e03194f3e77a39c1dcd7a1c27eca7
          Log:
          do not distribute ruby-runtime 0.13 (#101)

          see JENKINS-37353, JENKINS-37771 and JENKINS-38145

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Spilker Path: src/main/resources/artifact-ignores.properties http://jenkins-ci.org/commit/backend-update-center2/803812c3149e03194f3e77a39c1dcd7a1c27eca7 Log: do not distribute ruby-runtime 0.13 (#101) see JENKINS-37353 , JENKINS-37771 and JENKINS-38145

          ruby-runtime 0.13 is no longer available in the Update Center, you need to downgrade to 0.12 to fix the problem.

          Daniel Spilker added a comment - ruby-runtime 0.13 is no longer available in the Update Center, you need to downgrade to 0.12 to fix the problem.

            daspilker Daniel Spilker
            mvardi Menahem Vardi
            Votes:
            12 Vote for this issue
            Watchers:
            21 Start watching this issue

              Created:
              Updated:
              Resolved: