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

Commit has in run result header is not clickable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • blueocean-plugin
    • None
    • Blue Ocean 1.2-beta1, Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3, Blue Ocean 1.2-beta4

      We collect this data and display links for it elsewhere but we never made the commit has itself clickable https://cl.ly/1z1C3C3O3w1h

      In Scope

      • Make it clickable
      • Write a test (if possible)

          [JENKINS-45011] Commit has in run result header is not clickable

          James Dumay added a comment -

          cliffmeyers FYI - you are right that this wasn't clickable. Good catch.

          James Dumay added a comment - cliffmeyers FYI - you are right that this wasn't clickable. Good catch.

          James Dumay added a comment -

          nicu as for writing tests ping imeredith to give you an introduction (if you've not had one already)

          James Dumay added a comment - nicu as for writing tests ping imeredith to give you an introduction (if you've not had one already)

          Keith Zantow added a comment - - edited

          I looked into this a bit last week & yesterday, but there seems to be a particular issue - in order to get an appropriate link, the RepositoryBrowser needs to provide it, but the API requires a ChangeSet object, for which no API exists to convert from a commit id. The only cases where this is a problem is when a user directly runs a branch and there are no changes from the last run (not replays - replay copies the ChangeSet s from the prior run). As I see it, there are 3 possible solutions:

          One solution is simply to not show the commit id at all, as according to Jenkins there are no "changes" for the run despite having an SCMRevisionAction.

          A second solution is to try to look back through all prior runs to find a ChangeSet that matches the commitId in the SCMRevisionAction, this has the potential to not find one and scan the entire history or some bounded subset. In PipelineRunImpl.java this might look something like:

              @Exported(name = "commitUrl")
              public String getCommitUrl() {
                  String commitId = getCommitId();
                  if (commitId != null) {
                      Container<BlueChangeSetEntry> changeSets = getChangeSet();
                      int buildNumber = this.run.number;
                      WorkflowJob job = this.run.getParent();
                      while (buildNumber > 0) {
                      	BlueChangeSetEntry entry = changeSets.get(commitId);
                      	if (entry != null) {
                              return entry.getUrl();
                      	}
                          buildNumber--;
                          Run<?,?> run = job.getBuildByNumber(buildNumber);
                          if (run == null) {
                              continue;
                          }
                          changeSets = AbstractRunImpl.getBlueRun(run, parent).getChangeSet();
                      }
                  }
                  return null;
              }
          

          Another solution, which is a bit hackish, we can manually construct a ChangeSet object. This is directly dependent on the RepositoryBrowser class, though and would require some specific type-checking for known repository browsers.

          Keith Zantow added a comment - - edited I looked into this a bit last week & yesterday, but there seems to be a particular issue - in order to get an appropriate link, the RepositoryBrowser needs to provide it, but the API requires a ChangeSet object, for which no API exists to convert from a commit id . The only cases where this is a problem is when a user directly runs a branch and there are no changes from the last run (not replays - replay copies the ChangeSet s from the prior run). As I see it, there are 3 possible solutions: One solution is simply to not show the commit id at all, as according to Jenkins there are no "changes" for the run despite having an SCMRevisionAction . A second solution is to try to look back through all prior runs to find a ChangeSet that matches the commitId in the SCMRevisionAction , this has the potential to not find one and scan the entire history or some bounded subset. In PipelineRunImpl.java this might look something like: @Exported(name = "commitUrl" ) public String getCommitUrl() { String commitId = getCommitId(); if (commitId != null ) { Container<BlueChangeSetEntry> changeSets = getChangeSet(); int buildNumber = this .run.number; WorkflowJob job = this .run.getParent(); while (buildNumber > 0) { BlueChangeSetEntry entry = changeSets.get(commitId); if (entry != null ) { return entry.getUrl(); } buildNumber--; Run<?,?> run = job.getBuildByNumber(buildNumber); if (run == null ) { continue ; } changeSets = AbstractRunImpl.getBlueRun(run, parent).getChangeSet(); } } return null ; } Another solution, which is a bit hackish, we can manually construct a ChangeSet object. This is directly dependent on the RepositoryBrowser class, though and would require some specific type-checking for known repository browsers.

            nicu Nicolae Pascu
            jamesdumay James Dumay
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: