I think GoCD works the way it works because it needs to support "Trigger with Options <https://docs.gocd.org/current/advanced_usage/trigger_with_options.html>" (ability to rollback to a different version of a material). That way storing "greater" as anything new makes sense to me personally.
Talking about "Trigger with Options" -- In your case wasn't using it on the respective pipeline(s) with the older version of the package an option? On Thu, Oct 19, 2017 at 9:07 PM, David Delger <[email protected]> wrote: > 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 >> Sent: 19-10-2017 04:49 >> To: go-cd >> 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/packag >> e_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]. >> 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. > -- Ashwanth Kumar / ashwanthkumar.in -- 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.
