* Ensure options for formulas `git.latest` are also based on defaults
* Prevent erroneous remote tracking branch modification by `salt.formulas` #238
* Allow multiple envs to use the same gitdir for `salt.formulas`
* Ensure `gitdir` original branch is checked out after formulas `git.latest`
* Fix erroneous comment re: merging in `salt` pillar
* Add MacOS support; fix Issue #352
* On MacOS, only attempt download if condition
Add if salt_settings.install_packages to requisites for an attempt to download the minion package on MacOS
* Update example pillar for MacOS support
Describe how to use MacOS specific options
* Add MacOS notes
* Update README.rst
* Update README.rst
I use Salt environments to provide each of my team mates the ability to develop
and test their Salt changes. And I've found that when we run this formula from
our environments against our salt-master, comments in some files change. For us
this represents an unwanted and unplanned change. I understand the intention -
to identify how or why the file changed, but I firmly believe that we should
be able to run highstsate with test=True and only see intended changes. Here's
an example:
ID: salt-cloud-providers
Function: file.recurse
Name: /etc/salt/cloud.providers.d
Result: None
Comment: #### /etc/salt/cloud.providers.d/saltify.conf ####
The file /etc/salt/cloud.providers.d/saltify.conf is set to be changed
Started: 20:01:28.586441
Duration: 75.185 ms
Changes:
----------
/etc/salt/cloud.providers.d/saltify.conf:
----------
diff:
---
+++
@@ -1,4 +1,4 @@
-# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=myenv
+# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=dev
saltify:
provider: saltify
SaltStack provides "versioned" repositories, this commit add a way
to set which release of salt to use.
It adds a pillar "salt:release" which can be set to a specific release
(ex: 2016.11). This release is then used to configure properly the
repositories URLs for Debian/Ubuntu/RedHat.
The default behavior is to point to 'latest', retaining the previous
behavior if the "salt:release" pillar is not set.
As discussed in PR#305, these are defaults that even if they are
configurable as probably not suited to a majority of users and causes
delete/add output on highstate of user of the formula choses to use
the same file name.
Since the set of directories is known, just iterate of its well known
names directly. Make sure files are dumped after `file.recurse` to avoid
deletion/creation cycles when applying highstate.
Also apply permissions on cloud.providers.d after all creations steps
are done.