(RFC) native types and providers #382
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* user_update() creates or updates a single user from JSON * user_info_all() dumps all current users in JSON
…ance() methods to puppet_helper
This class provides configuration values to override defaults and fact data for PuppetX::Jenkins::Provider::Clihelper based providers.
This class is used to lookup common configuration values by first looking for the desired key as parameter to the config class in the catalog, then checking for a prefixed fact, and falling back to hard coded defaults.
This is a base class for providers that need to interact with jenkins via the puppet_helper.groovy script.
Wraps Puppet::Type::newtype and sets up the type level autorequires needed for PuppetX::Jenkins::Provider::Cli subclass providers.
Provides unundef() & undefize() methods for [un]munging data.
…_helper * credentials_list_json() list all credentials in the `global` domain as a JSON document to the stdout * credentials_update_json() modify an existing credentials specified by a JSON document passed via the stdin * credentials_delete_id() remove a credentials by `id`
* job_enabled() print the job's state as either "true" or "false"
This was referenced Oct 2, 2015
Closed
Open
|
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
|
I think this is worth including. i'm not sure, past defaulting these behaviors, how to encourage their usage though |
rtyler
pushed a commit
that referenced
this pull request
Oct 5, 2015
(RFC) native types and providers
|
@rtyler I agree that advertising this will be difficult. Perhaps add a section to the README about experimental types? There is a todo in my usage notes for known issues. In particular, I think there needs to be some discussion about the |
This was referenced Oct 10, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a family of native types and providers with the aim of replacing direct usage of the
clijar viaexecresources (E.g.jenkins::cli:exec). The principle motivation is to resolve the "chicken vs egg" problem that occurs between theclijar and jenkins when enabling security. Similarly, it provides a mechanism to set the API token on a user account that can be used for the connection of swarm clients, which otherwise are unable to connect when using a security realm that does not use password (E.g. github-oauth). It should be relatively easy to extend these types to provide additional functionality, such as supporting additional credentials types.No attempt has been made to integrate the new types into the existing classes and defined types. It should be possible to try them out in an essentially stand alone fashion against a running jenkins instance. Preliminary and extremely terse notes are in NATIVE_TYPES_AND_PROVIDERS.md.
Comments, feedback, and/or bug reports would be greatly welcomed.