Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: perforce-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.538
      Plugin 1.3.26
    • Similar Issues:

      Description

      The <firstChange> property seems to change between 0 and -1 for no apparent reason, and with no user interaction.
      This is very annoying if you're keeping job configs under version control.

        Attachments

          Issue Links

            Activity

            Hide
            jameshowe James Howe added a comment -

            The <clientOwner> also appears and disappears in a similar fashion, but not at the same time.

            Show
            jameshowe James Howe added a comment - The <clientOwner> also appears and disappears in a similar fashion, but not at the same time.
            Hide
            rpetti Rob Petti added a comment -

            I can't say I've ever seen that before. clientOwner definitely shouldn't change unless you change it, but firstChange might change it's value if you change the way the plugin syncs (syncing to head one build, then syncing to a changeset the next build, etc).

            Another possibility is that these values are (at least partially) transient, and that deserialization during startup is causing the issue. Do you frequently restart Jenkins or reload configuration from disk?

            Show
            rpetti Rob Petti added a comment - I can't say I've ever seen that before. clientOwner definitely shouldn't change unless you change it, but firstChange might change it's value if you change the way the plugin syncs (syncing to head one build, then syncing to a changeset the next build, etc). Another possibility is that these values are (at least partially) transient, and that deserialization during startup is causing the issue. Do you frequently restart Jenkins or reload configuration from disk?
            Hide
            jameshowe James Howe added a comment -

            It doesn't seem related to startup or reloading. It may correspond to running the job, but I don't have evidence for that.

            Show
            jameshowe James Howe added a comment - It doesn't seem related to startup or reloading. It may correspond to running the job, but I don't have evidence for that.
            Hide
            jameshowe James Howe added a comment -

            To clarify <clientOwner>, it changes between "<clientOwner></clientOwner>" and being omitted entirely.

            Show
            jameshowe James Howe added a comment - To clarify <clientOwner>, it changes between "<clientOwner></clientOwner>" and being omitted entirely.
            Hide
            maccer Mac Cer added a comment -

            I agree that this is very annoying. It is not every job and not after every run which makes it even weirder.
            I have the jobs' configs in Perforce, as well and it would be great if I could do some configuration on some jobs and then simply run "p4 reconcile" to get the deltas.
            Which should just be the things I just changed. But with this behavior, I will always get x other job changes checked in that really have not changed except for the firstChange property. Alternating between 0 and -1.

            I am wondering what that property is used for and what would happen if one manually deleted that row in the jobs' config xml...

            It would be a dirty workround, but in case that property does nothing important, one coudl remove that row of the xml with some awk or sed in a script that simply runs over every job config xml before one checks in ones changes.

            Show
            maccer Mac Cer added a comment - I agree that this is very annoying. It is not every job and not after every run which makes it even weirder. I have the jobs' configs in Perforce, as well and it would be great if I could do some configuration on some jobs and then simply run "p4 reconcile" to get the deltas. Which should just be the things I just changed. But with this behavior, I will always get x other job changes checked in that really have not changed except for the firstChange property. Alternating between 0 and -1. I am wondering what that property is used for and what would happen if one manually deleted that row in the jobs' config xml... It would be a dirty workround, but in case that property does nothing important, one coudl remove that row of the xml with some awk or sed in a script that simply runs over every job config xml before one checks in ones changes.
            Hide
            rpetti Rob Petti added a comment -

            If you manually deleted it, then it would just re-add it on the next run. It's used for configuring whether which change to start pulling changes from, so that the first build of an old project does not try to get a million changes from your SCM.

            Show
            rpetti Rob Petti added a comment - If you manually deleted it, then it would just re-add it on the next run. It's used for configuring whether which change to start pulling changes from, so that the first build of an old project does not try to get a million changes from your SCM.

              People

              • Assignee:
                Unassigned
                Reporter:
                jameshowe James Howe
              • Votes:
                1 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: