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

Migrate from SCMHead to concrete subclass

    XMLWordPrintable

Details

    • Improvement
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • git-plugin
    • None

    Description

      We need a concrete subclass to allow determination of the refspec to be made

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            I am guessing this is intended to assist in a fix of JENKINS-48061?

            jglick Jesse Glick added a comment - I am guessing this is intended to assist in a fix of  JENKINS-48061 ?

            That is just part. There are also people who want to be able to discover refs that are not in refs/heads

            stephenconnolly Stephen Connolly added a comment - That is just part. There are also people who want to be able to discover refs that are not in refs/heads
            stephenconnolly Stephen Connolly added a comment - - edited

            To clarify, a full fix of JENKINS-48061 requires to handle two cases:

            1. The case where the revision is contained in the history of at least one branch in refs/heads/*:refs/remotes/@{remote}/*
            2. The case where the revision is either not advertised as a head (rare and I expect we could fail for that case) or is advertised as a ref but not a ref in refs/heads (much more common, but should still be rare... in most cases a regular branch will contain the revision somewhere in its history)

            Fixing the first case is a case of changing client.getBranchesContaining(hash, false) to client.getBranchesContaining(hash, true) and the follow-up of reconstructing the branch name from the local checkout's remote refs. This first case does not require this change

            Fixing the second case requires this change as we need to tell GitSCMBuilder to construct a different refspec other than +refs/heads/${SCMHead.getName()}:refs/remotes/@{remote}/${SCMHead.getName()} which would blow up both for a raw revision and for a ref that is not in refs/heads in the remote repository

            stephenconnolly Stephen Connolly added a comment - - edited To clarify, a full fix of  JENKINS-48061  requires to handle two cases: The case where the revision is contained in the history of at least one branch in refs/heads/*:refs/remotes/@{remote}/* The case where the revision is either not advertised as a head (rare and I expect we could fail for that case) or is advertised as a ref but not a ref in refs/heads (much more common, but should still be rare... in most cases a regular branch will contain the revision somewhere in its history) Fixing the first case is a case of changing client.getBranchesContaining(hash, false)  to client.getBranchesContaining(hash, true) and the follow-up of reconstructing the branch name from the local checkout's remote refs. This first case does not require this change Fixing the second case requires this change as we need to tell GitSCMBuilder to construct a different refspec other than +refs/heads/${SCMHead.getName()}:refs/remotes/@{remote}/${SCMHead.getName() } which would blow up both for a raw revision and for a ref that is not in refs/heads in the remote repository

            Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

            stephenconnolly Stephen Connolly added a comment - Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

            People

              Unassigned Unassigned
              stephenconnolly Stephen Connolly
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated: