Jira (PUP-2019) Expose catalog version

2019-10-20 Thread Nathan Grubb (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Nathan Grubb commented on  PUP-2019  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Expose catalog version   
 

  
 
 
 
 

 
 If it's no possible to add, could someone point me to how I can expose a variable to a manifest file. The catalog version isn't available until after facts are generated so I can't add it to facter and seems like all variables are put there, but perhaps there is another easy way?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.29636.1395577137000.8571.1571587080212%40Atlassian.JIRA.


Jira (PUP-2019) Expose catalog version

2019-10-20 Thread Nathan Grubb (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Nathan Grubb commented on  PUP-2019  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Expose catalog version   
 

  
 
 
 
 

 
 I guess this isn't super in demand since this ticket is quite old, but if possible I would like this functionality. I tried adding it myself, but it didn't seem trivial. I'm using a puppet server with environment configuration backed by git and setting config_version to git parse-rev HEAD. I would like to access what the config_version/catalog.version/configuration_version from a manifest file. The reason for this is because I'm using Jenkins CasC and would like to put in the description the exact link in Git to the template that was used to configure Jenkins with.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.29636.1395577137000.8569.1571586960117%40Atlassian.JIRA.


Jira (PDOC-295) Add support for @enum tag

2019-10-20 Thread Sean Millichamp (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Sean Millichamp commented on  PDOC-295  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add support for @enum tag
 

  
 
 
 
 

 
 A PR which I believe implements this correctly is up here for consideration: https://github.com/puppetlabs/puppet-strings/pull/215 Thanks!  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.330991.1571580412000.8564.1571580540040%40Atlassian.JIRA.


Jira (PDOC-295) Add support for @enum tag

2019-10-20 Thread Sean Millichamp (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Sean Millichamp created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Strings /  PDOC-295  
 
 
  Add support for @enum tag
 

  
 
 
 
 

 
Issue Type: 
  New Feature  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2019/10/20 7:06 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Sean Millichamp  
 

  
 
 
 
 

 
 Puppet Strings currently supports, via YARD, the ability to add extended documentation to a parameter which expects a hash to document the various keys expected using the @option tag. This is quite useful. Parameters that are of the Puppet Enum type would also benefit from this type of extended option documentation. However, the @option tag is not suitable as it expects a data type to be provided, which makes no sense in the context of an Enum. You can put an arbitrary value as the datatype, but it results in a poor user experience for both the person documenting and the person reading the documentation. Instead I propose adding a new tag, @enum, that behaves similarly to @option but does not expect a data type to be passed and renders the results accordingly (but otherwise similarly to @option).    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment