Bump version, add OS support, bugfixes and more #1
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
I'm not sure there is a use-case for this being optional at this point (since the hashes are already supplied for the default version), but it seems that the intent was always to allow this to be optional.
* The `file: svc.sh`-type requirement was invalid since it did not reference a state. * Redundant requirements specified. * Ordering of cmd and service is now more logical (and alphabetical!). * Use `creates` instead of `watch` to check if needed. * Fetch the service name from the generated .service file.
The .service file won't exist at the time the template is rendered on the first run.
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 includes the following changes:
You could consider this a breaking change, but it was already not working to begin with.
One other thing to note is that the token appears to be one-time use, so if the plan is to run this state on a bunch of hosts, the user would need to find a way to generate tokens on-demand. However, a token is only used for the initial setup of a host and never looked at again. If just two runners were required, one could set the token in pillar, launch one, change the token in pillar, then launch the second. This isn't great, but it's an option.
Having said that, the way the token works isn't new to this PR; it's just that now we have repo_token documented in the pillar.