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

Build based on a specific Perforce Changelist number.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      We have a need to trigger Hudson to build a project tree based on a known
      Perforce Changelist number. This may seem backwards from the Hudson paradigm,
      but our existing build system checks out a build ID file and increments a build
      counter along with saving the Changelist number being used to submit the
      change. This Changelist number is then used to synch the entire branch to a
      known moment in time. This approach was chosen over applying a label to avoid
      the overhead of applying 4-5000 labels to our source. Using the known
      Changelist eleminates mistakenly including any changes that occur after the
      know point in time.

      Is this possible using the Perforce plugin, or with any combination of existing
      plugins?

      Would this be a feasable/desirable enhancement for the existing Perforce plugin?

        Attachments

          Activity

          Hide
          torbent torbent added a comment -

          Just a quick note (to self and others): The use of "p4 counter" requires that the Hudson Perforce user has "review" permissions. I'll see if I can grow one of those

          Show
          torbent torbent added a comment - Just a quick note (to self and others): The use of "p4 counter" requires that the Hudson Perforce user has "review" permissions. I'll see if I can grow one of those
          Hide
          rpetti Rob Petti added a comment -

          Another quick note: This can also be accomplished by parameter substitution in the Label field of the perforce configuration. That will cause the plugin to sync to whatever changeset or label is passed into the build. That way you don't need any additional permissions on the perforce server.

          Show
          rpetti Rob Petti added a comment - Another quick note: This can also be accomplished by parameter substitution in the Label field of the perforce configuration. That will cause the plugin to sync to whatever changeset or label is passed into the build. That way you don't need any additional permissions on the perforce server.
          Hide
          torbent torbent added a comment -

          Syncing to a label is not the problem; I think we do that for more than half of our jobs
          The problem is rather actually labeling a build so a downstream job can sync to the same point in "time".
          Right now, our build script runs a 'p4 label' command after the actual build. The label is always called the same, but moves forward in the changelist numbers. But as I've written in JENKINS-4928 this means that we lose changeset information downstream.
          I might try one or both of these:

          • Using a new label for all builds, and passing its name as a parameter downstream. A downside is the number of new labels this will result in. But will it give us changesets downstream?
          • Using this counter-idea will eliminate the labels. But will it give us changesets downstream?
            A question (although it sort of feels like hijacking the issue): When are the parameters expanded? It seems slightly magic. Can I e.g. use JOB_NAME in client name?
          Show
          torbent torbent added a comment - Syncing to a label is not the problem; I think we do that for more than half of our jobs The problem is rather actually labeling a build so a downstream job can sync to the same point in "time". Right now, our build script runs a 'p4 label' command after the actual build. The label is always called the same, but moves forward in the changelist numbers. But as I've written in JENKINS-4928 this means that we lose changeset information downstream. I might try one or both of these: Using a new label for all builds, and passing its name as a parameter downstream. A downside is the number of new labels this will result in. But will it give us changesets downstream? Using this counter-idea will eliminate the labels. But will it give us changesets downstream? A question (although it sort of feels like hijacking the issue): When are the parameters expanded? It seems slightly magic. Can I e.g. use JOB_NAME in client name?
          Hide
          rpetti Rob Petti added a comment -

          I didn't mean actually using labels, I meant passing the changeset in as a parameter in the Label configuration field. When syncing, it'll use p4 sync //workspace/...@${label} where ${label} is expanded appropriately. So it doesn't matter if label is set to a changeset, or an actual label.

          I don't think either of these methods will give you changelogs downstream, unfortunately. There's simply no way to accurately describe the state of the last sync when using labels or changesets. There might be a plugin for propagating changelogs downstream, however.

          Parameters are expanded in the View and the Label configuration fields only. The parameters that are expanded are the ones defined by the "Parameterized Build" functionality. This doesn't include the built-in ones (eg, JOB_NAME) as far as I know.

          Show
          rpetti Rob Petti added a comment - I didn't mean actually using labels, I meant passing the changeset in as a parameter in the Label configuration field. When syncing, it'll use p4 sync //workspace/...@${label} where ${label} is expanded appropriately. So it doesn't matter if label is set to a changeset, or an actual label. I don't think either of these methods will give you changelogs downstream, unfortunately. There's simply no way to accurately describe the state of the last sync when using labels or changesets. There might be a plugin for propagating changelogs downstream, however. Parameters are expanded in the View and the Label configuration fields only. The parameters that are expanded are the ones defined by the "Parameterized Build" functionality. This doesn't include the built-in ones (eg, JOB_NAME) as far as I know.
          Hide
          torbent torbent added a comment -

          Ah yes, I see. Passing changesets that way would probably be OK. I should try.

          I thought the 'p4 counter' solution might be able to provide changelogs. The job would know the value of the counter (same as changelist number) for every build and should be able to find all changes between those. Precisely like it does for the polling.
          Of course, if the plugin wants to be very defensive, I must admit that of course it's possible to play games with the counters and update them behind the scenes (even back in time). Although you technically can do that with changelist numbers as well, that series of numbers is always increasing.

          Show
          torbent torbent added a comment - Ah yes, I see. Passing changesets that way would probably be OK. I should try. I thought the 'p4 counter' solution might be able to provide changelogs. The job would know the value of the counter (same as changelist number) for every build and should be able to find all changes between those. Precisely like it does for the polling. Of course, if the plugin wants to be very defensive, I must admit that of course it's possible to play games with the counters and update them behind the scenes (even back in time). Although you technically can do that with changelist numbers as well, that series of numbers is always increasing.

            People

            • Assignee:
              rpetti Rob Petti
              Reporter:
              scottlavender scottlavender
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: