I appreciate the detailed response. I've done some more local testing, recreating the scenario, and I'm seeing basically what you described.
It seems that 'greater' simply means different. Publishing an old revision, even with a newer timestamp has no affect. This essentially prevents us from 'rolling back' a version. Our scenario is that we upgrade our environments once a day at a specified time. We pull the version from a central repository. The plugin simply pulls the latest version from the repository. Yesterday we promoted version X and upgraded our environment. This morning we promoted version Y. However, before the upgrade time occurred we identified an issue with version Y and reverted back to X in the central repository. The plugin identified this but during the time that Y had been promoted it published that version to GoCD. Later it started publishing X again, however as described below and seen in my testing GoCD does not honor this at it sees X as 'not different' from Y since X already exists in it's cache. This caused our environment to upgrade to Y and included the bug we found earlier. Why wouldn't GoCD simply honor the last revision published by the plugin? Presumably the author of the plugin is more aware of what they want the latest revision to be then GoCD. A quick hack / workaround I have is to simply append the timestamp to the revision. Then I would publish the actual revision via the 'data' field in the message so that it is available to the pipeline via an environment variable. On Wednesday, October 18, 2017 at 7:29:06 PM UTC-5, Ashwanth Kumar wrote: > > I'm taking a stab at this. I don't know how GoCD internally does it, but > based on my experience writing the GitHub PR plugin it looks like it stores > all versions we emit and always considers something new for versions that > it has not seen before. > > Consider the case of git hashes. There isn't any timestamp or ordering > defined in the hashes. As soon as a new (or set of new) version(s) are > available it would trigger the respective pipelines or do whatever that > needs to be done. > > We also have a timestamp field that we emit as part of the response to > this plugin method. Since GoCD batches scm updates it might be sorting the > revisions based on the timestamp to denote the latest revision on pipeline > trigger. > > So to summarise my understanding is, GoCD uses set of all versions to > identify if a version is new or not. Based on the fact if it has seen it or > not. And optionally might use the timestamp field for ordering the > revisions when batching the updates. > > Would love to hear from the core team on how it is actually implemented > under the hood. > > Text by Ashwanth, typos by Lumia > ------------------------------ > From: David Delger <javascript:> > Sent: 19-10-2017 04:49 > To: go-cd <javascript:> > Subject: [go-cd] How is package material plugin latest version determined? > > I've created a custom package material plugin. However today I saw some > strange results when the material was bumped but later reverted to a lower > version. I'm trying to understand what the documentation means when it says > the following. > > > https://developer.gocd.org/current/writing_go_plugins/package_material/version_1_0/latest_revision_since.html > > "The difference here, is that it needs to find a revision of the package > which is *greater* than the one specified in the request." > > How does it determine greater? Timestamp? String compare on the revision > field? > > -- > You received this message because you are subscribed to the Google Groups > "go-cd" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
