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

Jenkins Credential updated but git doesn't use it

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • Jenkins 2.452.2, GitLab Branch Source 704.vc7f1202d7e14, GitLab API 530-91.v1f9a_fda_d654f, Git 5.2.2, Git client plugin 5.0.0, Git Parameter Plug-In 0.9.19, Git server Plugin 126.v0d945d8d2b_39, Windows

      GitLab starting from 16.0 version does not have non-expiry access token. The original non-expiry token had become expired after one year. We recently updated the access token stored in the Jenkins Credential before the expiry. However, the updated access token was not correctly used.

      The credential ci-bot is used but the log showing the actual credential being used is not ci-bot.

      i.e. 

      expected credential -> ci-bot:password1
      actual credential used -> user1:password2

          [JENKINS-73700] Jenkins Credential updated but git doesn't use it

          Mark Waite added a comment - - edited

          You'll need to provide more details so that others can duplicate the issue. I'm unavailable for the next two weeks, so I won't attempt to duplicate the issue, but as far as I can tell from reading the description, it is unlikely that I will be able to duplicate the issue as described. Needs step by step instructions.

          You may have failed to update the credential definition that is saved on the Jenkins global configuration page. You may have failed to update the credential definition in the Jenkins job definition. Check them both.

          Mark Waite added a comment - - edited You'll need to provide more details so that others can duplicate the issue. I'm unavailable for the next two weeks, so I won't attempt to duplicate the issue, but as far as I can tell from reading the description, it is unlikely that I will be able to duplicate the issue as described. Needs step by step instructions. You may have failed to update the credential definition that is saved on the Jenkins global configuration page. You may have failed to update the credential definition in the Jenkins job definition. Check them both.

          Angus added a comment - - edited

          Mark,

          Thanks for your instant reply, I'm Angus and colleague of Wayne. Please find the information for our environment at below: 

          Existing Environment:

          1. GitLab (version 17.1.1): Serving as the source code repository.
          2. Jenkins (version 2.452.2): Acting as the CI pipeline executor.

          CI Pipeline Procedure:

          1. Users update the code in GitLab and create a new Tab.
          2. Jenkins periodically polls the GitLab repository for new Tab with a service account token.
          3. Jenkins checks out the repository to retrieve information about the new Tab by service account token.
          4. Jenkins executes the CI pipeline, which includes fetching necessary libraries from a global trusted pipeline library repository, also using the service account token.
          5. The CI pipeline then tests, scans, and builds the code, after which it posts the results back to GitLab and pushes the artifact to Nexus.

          Issue:

          Initially, the service account token was set to never expire. However, after upgrading GitLab to version 16 last year, tokens are now configured to expire annually. We generated a new token in GitLab and updated the credentials in Jenkins accordingly. Despite this, the CI pipeline continues to fail. Upon investigation, we noticed that the updated token does not display the username and token as expected, leading to the pipeline’s inability to run successfully.

          Angus added a comment - - edited Mark, Thanks for your instant reply, I'm Angus and colleague of Wayne. Please find the information for our environment at below:  Existing Environment: GitLab (version 17.1.1):  Serving as the source code repository. Jenkins (version 2.452.2):  Acting as the CI pipeline executor. CI Pipeline Procedure: Users update the code in GitLab and create a new Tab. Jenkins periodically polls the GitLab repository for new Tab with a service account token. Jenkins checks out the repository to retrieve information about the new Tab by service account token. Jenkins executes the CI pipeline, which includes fetching necessary libraries from a global trusted pipeline library repository, also using the service account token. The CI pipeline then tests, scans, and builds the code, after which it posts the results back to GitLab and pushes the artifact to Nexus. Issue: Initially, the service account token was set to never expire. However, after upgrading GitLab to version 16 last year, tokens are now configured to expire annually. We generated a new token in GitLab and updated the credentials in Jenkins accordingly. Despite this, the CI pipeline continues to fail. Upon investigation, we noticed that the updated token does not display the username and token as expected, leading to the pipeline’s inability to run successfully.

          Slawomir added a comment - - edited

          Hi angus_yuen 

          I believe we encounter the same issue lately on our Jenkins Server. For a long time, we were using technical user with non-expiry password. Lately we switched to the new user/password set and started issues with bb communication (Jenkins were not able to access to bb). After some investigation we found out that Jenkins still using old credential   which were not valid at that point of time. 

          Going deep we find out that Jenkins is still using old credentials:

          == Info: Re-using existing connection with host bb 

          Later we checked git ls-remote form Jenkins container which gave as some interesting output:

          jenkins_container:/# GIT_CURL_VERBOSE=1 git ls-remote -h -- https://<bb_address>/project.git HEAD
          10:04:23.575570 http.c:845              == Info: Couldn't find host bb in the .netrc file; using defaults 

          So, we have actually found .netrc file in jenkins home directory which contained:

          server:/path/to/jenkins/home# cat .netrc 
          machine bb
                                  login not_valid_user
                                  password not_valid_password 

          After removing .netrc from jenkins home directory we were able to use new user credentials. Hope this may help with your issue.

          At the moment we are not able to determine if file was created as Workaround for the issue with git plugin or it was created due to bug in some old plugin version (double checked and can not find the file on ewer instance of our Jenkins).

           

          Best Regards

          Slawomir

          Slawomir added a comment - - edited Hi angus_yuen   I believe we encounter the same issue lately on our Jenkins Server. For a long time, we were using technical user with non-expiry password. Lately we switched to the new user/password set and started issues with bb communication (Jenkins were not able to access to bb). After some investigation we found out that Jenkins still using old credential   which were not valid at that point of time.  Going deep we find out that Jenkins is still using old credentials: == Info: Re-using existing connection with host bb Later we checked git ls-remote form Jenkins container which gave as some interesting output: jenkins_container:/# GIT_CURL_VERBOSE=1 git ls-remote -h -- https: //<bb_address>/project.git HEAD 10:04:23.575570 http.c:845              == Info: Couldn't find host bb in the .netrc file; using defaults So, we have actually found .netrc file in jenkins home directory which contained: server:/path/to/jenkins/home# cat .netrc  machine bb                         login not_valid_user                         password not_valid_password After removing .netrc from jenkins home directory we were able to use new user credentials. Hope this may help with your issue. At the moment we are not able to determine if file was created as Workaround for the issue with git plugin or it was created due to bug in some old plugin version (double checked and can not find the file on ewer instance of our Jenkins).   Best Regards Slawomir

            Unassigned Unassigned
            waynelwh Wayne
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: