It is an option and it's what we used to perform the rollback. I guess I'd prefer that we never upgrade to that version in the first place though. Since we identified the issue prior to the upgrade trigger we could have avoided this entirely.
I had assumed the Trigger with Options list would contain only the old revisions that were run against, not all revisions reported by the plugin but that appears to be incorrect. It seems this may be an atypical use case. On Thu, Oct 19, 2017 at 11:25 AM, 'Ashwanth Kumar' via go-cd < [email protected]> wrote: > 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 a topic in the > Google Groups "go-cd" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/go-cd/VVL4ATZf_qw/unsubscribe. > To unsubscribe from this group and all its topics, 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.
