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

Ancestry Maximum Age strategy causing "Couldn't find any revision to build"

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None
    • Ubuntu 20.04.4 LTS
      Jenkins 2.346.1
      openjdk version "1.8.0_312"
      OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~20.04-b07)
      OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)

      I have several jobs that specify Strategy for choosing what to build / Ancestry / Maximum Age of Commit. This is to prevent old heads unnecessarily building or dangerously deploying.

      Since a recent upgrade to Jenkins and/or the git plugin, jobs that have this config are refusing to rebuild any commit that has already built, irrespective of the age of commit.

      For example, a job that run on a daily basis (it is date-dependent and should start failing when some data is out-of-date), will build a given commit once, but will start failing on subsequent days with a log similar to below:

       

      Building in workspace /var/lib/jenkins/workspace/XXX
      The recommended git tool is: NONE
      using credential XXX
       > git rev-parse --resolve-git-dir /var/lib/jenkins/workspace/XXX/.git # timeout=10
      Fetching changes from the remote Git repository
       > git config remote.origin.url XXX.git # timeout=10
      Fetching upstream changes from XXX.git
       > git --version # timeout=10
       > git --version # 'git version 2.37.0'
      using GIT_SSH to set credentials 
       > git fetch --tags --force --progress -- XXX.git +refs/heads/*:refs/remotes/origin/* # timeout=10
      Seen branch in repository origin/HEAD
      Seen branch in repository origin/master
      Seen branch in repository origin/v10
      Seen 3 remote branches
       > git show-ref --tags -d # timeout=10
      ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
      Finished: FAILURE 

       

      Branch specifier in this example is set to **

      Another case uses refs/tags/release.*

      What I've tried:

      • Recreating the job — same outcome
      • Removing the git strategy — works as expected but liable to start building everything (e.g. every tag) so not a good strategy
      • Commit in ancestry — same outcome
      • Deleting the previous build for the commit — will rebuild, but only good as a manual intervention
      • Deleting the workspace — same outcome

       

      Workarounds

      • In one job I only need to run the regular rebuild on master, so created a duplicate job that specifies master (allowing me to delete the Max Age strategy)
      • Another job that matches by tag, I can manually delete previous build information if I need to rebuild from the same commit. Removing the Max Age strategy isn't possible because old release tags would start deploying to production :-o

       

      Could be related to https://issues.jenkins.io/browse/JENKINS-43220

          [JENKINS-69015] Ancestry Maximum Age strategy causing "Couldn't find any revision to build"

          Travis added a comment -

          Any update on this or how to get around this error?  I am in the process of upgrading Jenkins and when I upgrade this plugin we start receiving this error.  I'm not sure how to get around this.

          Thanks,
          Travis

          Travis added a comment - Any update on this or how to get around this error?  I am in the process of upgrading Jenkins and when I upgrade this plugin we start receiving this error.  I'm not sure how to get around this. Thanks, Travis

          Hi Travis, I had a quick look and I don't think we found a solution.

          The build/deploys that have failed since last July have been due to a bad commit rather than a bad build (meaning we've always pushed a new commit rather than adjusting build settings and trying to rebuild).

          Basically we've not had to deal with the issue. If it happens again, I'm guessing we'll have to either delete the bad build or push a dummy commit to force a new build.

          Rob.

          Robert Churchill added a comment - Hi Travis, I had a quick look and I don't think we found a solution. The build/deploys that have failed since last July have been due to a bad commit rather than a bad build (meaning we've always pushed a new commit rather than adjusting build settings and trying to rebuild). Basically we've not had to deal with the issue. If it happens again, I'm guessing we'll have to either delete the bad build or push a dummy commit to force a new build. Rob.

          Travis added a comment -

          So would you say to just move forward with our upgrade and not upgrade these plugins that cause this issue?  And at some point you think this will be corrected in a later update?

          Travis added a comment - So would you say to just move forward with our upgrade and not upgrade these plugins that cause this issue?  And at some point you think this will be corrected in a later update?

          I'm not a maintainer, so I'm not really sure on whether it can be fixed.

          Carrying on with the upgrade might depends on what issues are fixed (security etc) and how important they are to you.

          I think its possible to work around this issue by either deleting builds that have errored or by pushing a dummy commit. Assuming its the same root cause.

          Robert Churchill added a comment - I'm not a maintainer, so I'm not really sure on whether it can be fixed. Carrying on with the upgrade might depends on what issues are fixed (security etc) and how important they are to you. I think its possible to work around this issue by either deleting builds that have errored or by pushing a dummy commit. Assuming its the same root cause.

            Unassigned Unassigned
            idacrobert Robert Churchill
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: