• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin
    • None
    • Jenkins 1.538
      Plugin 1.3.26

      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.

          [JENKINS-21091] Config flip-flopping

          James Howe added a comment -

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

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

          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?

          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?

          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.

          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.

          James Howe added a comment -

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

          James Howe added a comment - To clarify <clientOwner>, it changes between "<clientOwner></clientOwner>" and being omitted entirely.

          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.

          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.

          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.

          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.

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

              Created:
              Updated: