saltstack/salt
1
0
Fork 0
mirror of https://github.com/saltstack/salt.git synced 2025-04-17 10:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Update docs for the configurable branch

Browse source
This commit is contained in:
Pedro Algarvio 2019-10-25 18:29:42 +01:00
parent 14bde12b9d
commit b8c2e75cf1
No known key found for this signature in database
GPG key ID: BB36BF6584A298FF
11 changed files with 55 additions and 55 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/ref/internals/fileserver-and-client.rst
View file

@ -44,8 +44,8 @@ will be skipped if the ``update`` function is run on the fileserver.
Backends for the fileserver are located in `salt/fileserver/`_ (the files not
named ``__init__.py``).
.. _`salt/fileserver/__init__.py`: https://github.com/saltstack/salt/tree/develop/salt/fileserver/__init__.py
.. _`salt/fileserver/`: https://github.com/saltstack/salt/tree/develop/salt/fileserver
.. _`salt/fileserver/__init__.py`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/fileserver/__init__.py
.. _`salt/fileserver/`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/fileserver
Fileclient
----------

2
doc/ref/returners/index.rst
View file

@ -383,4 +383,4 @@ Full List of Returners
.. toctree::
all/index
.. _`redis`: https://github.com/saltstack/salt/tree/develop/salt/returners/redis_return.py
.. _`redis`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/returners/redis_return.py

2
doc/ref/runners/all/salt.runners.mattermost.rst
View file

@ -3,7 +3,7 @@ salt.runners.mattermost
**Note for 2017.7 releases!**
Due to the `salt.runners.config <https://github.com/saltstack/salt/blob/develop/salt/runners/config.py>`_ module not being available in this release series, importing the `salt.runners.config <https://github.com/saltstack/salt/blob/develop/salt/runners/config.py>`_ module from the develop branch is required to make this module work.
Due to the `salt.runners.config <https://github.com/saltstack/salt/blob/|repo_primary_branch|/salt/runners/config.py>`_ module not being available in this release series, importing the `salt.runners.config <https://github.com/saltstack/salt/blob/|repo_primary_branch|/salt/runners/config.py>`_ module from the |repo_primary_branch| branch is required to make this module work.
Ref: `Mattermost runner failing to retrieve config values due to unavailable config runner #43479 <https://github.com/saltstack/salt/issues/43479>`_

4
doc/ref/states/writing.rst
View file

@ -21,7 +21,7 @@ illustrate:
.. code-block:: yaml
/etc/salt/master: # maps to "name", unless a "name" argument is specified below
file.managed: # maps to <filename>.<function> - e.g. "managed" in https://github.com/saltstack/salt/tree/develop/salt/states/file.py
file.managed: # maps to <filename>.<function> - e.g. "managed" in https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/states/file.py
- user: root # one of many options passed to the manage function
- group: root
- mode: 644
@ -59,7 +59,7 @@ A well-written state function will follow these steps:
This is an extremely simplified example. Feel free to browse the `source
code`_ for Salt's state modules to see other examples.
.. _`source code`: https://github.com/saltstack/salt/tree/develop/salt/states
.. _`source code`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/states
1. Set up the return dictionary and perform any necessary input validation
(type checking, looking for use of mutually-exclusive arguments, etc.).

6
doc/topics/cloud/cloud.rst
View file

@ -31,7 +31,7 @@ imports, to decide whether to load the module. In most cases, it will return a
filename, then that name should be returned instead of ``True``. An example of
this may be seen in the Azure module:
https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/msazure.py
https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/cloud/clouds/msazure.py
The get_configured_provider() Function
--------------------------------------
@ -57,7 +57,7 @@ created by the cloud host, wait for it to become available, and then
A good example to follow for writing a cloud driver module based on libcloud
is the module provided for Linode:
https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/linode.py
https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/cloud/clouds/linode.py
The basic flow of a ``create()`` function is as follows:
@ -183,7 +183,7 @@ imports should be absent from the Salt Cloud module.
A good example of a non-libcloud driver is the DigitalOcean driver:
https://github.com/saltstack/salt/tree/develop/salt/cloud/clouds/digitalocean.py
https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/cloud/clouds/digitalocean.py
The ``create()`` Function
-------------------------

2
doc/topics/cloud/deploy.rst
View file

@ -89,7 +89,7 @@ functions include:
A good, well commented example of this process is the Fedora deployment
script:
https://github.com/saltstack/salt/blob/develop/salt/cloud/deploy/Fedora.sh
https://github.com/saltstack/salt/blob/|repo_primary_branch|/salt/cloud/deploy/Fedora.sh
A number of legacy deploy scripts are included with the release tarball. None
of them are as functional or complete as Salt Bootstrap, and are still included

52
doc/topics/development/contributing.rst
View file

@ -78,12 +78,12 @@ Fork a Repo Guide_>`_ and is well worth reading.
git fetch upstream
git checkout -b fix-broken-thing upstream/2016.11
If you're working on a feature, create your branch from the develop branch.
If you're working on a feature, create your branch from the |repo_primary_branch| branch.
.. code-block:: bash
git fetch upstream
git checkout -b add-cool-feature upstream/develop
git checkout -b add-cool-feature upstream/|repo_primary_branch|
#. Edit and commit changes to your branch.
@ -149,7 +149,7 @@ Fork a Repo Guide_>`_ and is well worth reading.
.. code-block:: bash
git fetch upstream
git rebase upstream/develop add-cool-feature
git rebase upstream/|repo_primary_branch| add-cool-feature
git push -u origin add-cool-feature
If you do rebase, and the push is rejected with a
@ -185,9 +185,9 @@ Fork a Repo Guide_>`_ and is well worth reading.
https://github.com/my-account/salt/compare/saltstack:2016.11...fix-broken-thing
If your branch is a feature, choose ``develop`` as the base branch,
If your branch is a feature, choose ``|repo_primary_branch|`` as the base branch,
https://github.com/my-account/salt/compare/saltstack:develop...add-cool-feature
https://github.com/my-account/salt/compare/saltstack:|repo_primary_branch|...add-cool-feature
#. Review that the proposed changes are what you expect.
#. Write a descriptive comment. Include links to related issues (e.g.
@ -219,10 +219,10 @@ Fork a Repo Guide_>`_ and is well worth reading.
Salt's Branch Topology
----------------------
There are three different kinds of branches in use: develop, main release
There are three different kinds of branches in use: |repo_primary_branch|, main release
branches, and dot release branches.
- All feature work should go into the ``develop`` branch.
- All feature work should go into the ``|repo_primary_branch|`` branch.
- Bug fixes and documentation changes should go into the oldest **supported
main** release branch affected by the the bug or documentation change (you
can use the blame button in github to figure out when the bug was introduced).
@ -236,22 +236,22 @@ branches, and dot release branches.
.. note::
GitHub will open pull requests against Salt's main branch, ``develop``,
GitHub will open pull requests against Salt's main branch, ``|repo_primary_branch|``,
by default. Be sure to check which branch is selected when creating the
pull request.
The Develop Branch
==================
The |repo_primary_branch| Branch
================================
The ``develop`` branch is unstable and bleeding-edge. Pull requests containing
feature additions or non-bug-fix changes should be made against the ``develop``
The ``|repo_primary_branch|`` branch is unstable and bleeding-edge. Pull requests containing
feature additions or non-bug-fix changes should be made against the ``|repo_primary_branch|``
branch.
.. note::
If you have a bug fix or documentation change and have already forked your
working branch from ``develop`` and do not know how to rebase your commits
against another branch, then submit it to ``develop`` anyway. SaltStack's
working branch from ``|repo_primary_branch|`` and do not know how to rebase your commits
against another branch, then submit it to ``|repo_primary_branch|`` anyway. SaltStack's
development team will be happy to back-port it to the correct branch.
**Please make sure you let the maintainers know that the pull request needs
@ -298,7 +298,7 @@ automatically be "merged-forward" into the newer branches.
For example, a pull request is merged into ``2017.7``. Then, the entire
``2017.7`` branch is merged-forward into the ``2018.3`` branch, and the
``2018.3`` branch is merged-forward into the ``develop`` branch.
``2018.3`` branch is merged-forward into the ``|repo_primary_branch|`` branch.
This process makes is easy for contributors to make only one pull-request
against an older branch, but allows the change to propagate to all **main**
@ -338,7 +338,7 @@ message text directly. Only including the text in a pull request will not
close the issue.
GitHub will close the referenced issue once the *commit* containing the
magic text is merged into the default branch (``develop``). Any magic text
magic text is merged into the default branch (``|repo_primary_branch|``). Any magic text
input only into the pull request description will not be seen at the
Git-level when those commits are merged-forward. In other words, only the
commits are merged-forward and not the pull request text.
@ -348,7 +348,7 @@ commits are merged-forward and not the pull request text.
Backporting Pull Requests
=========================
If a bug is fixed on ``develop`` and the bug is also present on a
If a bug is fixed on ``|repo_primary_branch|`` and the bug is also present on a
currently-supported release branch, it will need to be back-ported to an
applicable branch.
@ -363,11 +363,11 @@ applicable branch.
changes themselves.
It is often easiest to fix a bug on the oldest supported release branch and
then merge that branch forward into ``develop`` (as described earlier in this
then merge that branch forward into ``|repo_primary_branch|`` (as described earlier in this
document). When that is not possible the fix must be back-ported, or copied,
into any other affected branches.
These steps assume a pull request ``#1234`` has been merged into ``develop``.
These steps assume a pull request ``#1234`` has been merged into ``|repo_primary_branch|``.
And ``upstream`` is the name of the remote pointing to the main Salt repo.
#. Identify the oldest supported release branch that is affected by the bug.
@ -450,20 +450,20 @@ the name of the main `saltstack/salt`_ repository.
git fetch upstream
#. Update your copy of the ``develop`` branch.
#. Update your copy of the ``|repo_primary_branch|`` branch.
.. code-block:: bash
git checkout develop
git merge --ff-only upstream/develop
git checkout |repo_primary_branch|
git merge --ff-only upstream/|repo_primary_branch|
If Git complains that a fast-forward merge is not possible, you have local
commits.
* Run ``git pull --rebase origin develop`` to rebase your changes on top of
* Run ``git pull --rebase origin |repo_primary_branch|`` to rebase your changes on top of
the upstream changes.
* Or, run ``git branch <branch-name>`` to create a new branch with your
commits. You will then need to reset your ``develop`` branch before
commits. You will then need to reset your ``|repo_primary_branch|`` branch before
updating it with the changes from upstream.
If Git complains that local files will be overwritten, you have changes to
@ -474,7 +474,7 @@ the name of the main `saltstack/salt`_ repository.
.. code-block:: bash
git push origin develop
git push origin |repo_primary_branch|
#. Repeat the previous two steps for any other branches you work with, such as
the current release branch.
@ -551,6 +551,6 @@ Script, see the Bootstrap Script's `Contributing Guidelines`_.
.. _GPG Probot: https://probot.github.io/apps/gpg/
.. _help articles: https://help.github.com/articles/signing-commits-with-gpg/
.. _GPG Signature Verification feature announcement: https://github.com/blog/2144-gpg-signature-verification
.. _bootstrap-salt.sh: https://github.com/saltstack/salt/blob/develop/salt/cloud/deploy/bootstrap-salt.sh
.. _bootstrap-salt.sh: https://github.com/saltstack/salt/blob/|repo_primary_branch|/salt/cloud/deploy/bootstrap-salt.sh
.. _salt-bootstrap repo: https://github.com/saltstack/salt-bootstrap
.. _Contributing Guidelines: https://github.com/saltstack/salt-bootstrap/blob/develop/CONTRIBUTING.md

10
doc/topics/development/tests/index.rst
View file

@ -69,7 +69,7 @@ test files for Salt execution modules.
in the ``test_module_name_source_match`` function. This unit test
ensures that we maintain the naming convention for test files.
.. __: https://github.com/saltstack/salt/blob/develop/tests/filename_map.yml
.. __: https://github.com/saltstack/salt/blob/|repo_primary_branch|/tests/filename_map.yml
Integration Tests
@ -416,13 +416,13 @@ Tests for New Features
If you are adding new functionality to Salt, please write the tests for this new
feature in the same pull request as the new feature. New features should always be
submitted to the ``develop`` branch.
submitted to the ``|repo_primary_branch|`` branch.
If you have already submitted the new feature, but did not write tests in the original
pull request that has already been merged, please feel free to submit a new pull
request containing tests. If the feature was recently added to Salt's ``develop``
request containing tests. If the feature was recently added to Salt's ``|repo_primary_branch|``
branch, then the tests should be added there as well. However, if the feature was
added to ``develop`` some time ago and is already present in one or more release
added to ``|repo_primary_branch|`` some time ago and is already present in one or more release
branches, please refer to the `Tests for Entire Files or Functions`_ section below
for more details about where to submit tests for functions or files that do not
already have tests.
@ -448,7 +448,7 @@ earliest supported release branch that contains the file or function you're test
Once your tests are submitted in a pull request and is merged into the branch in
question, the tests you wrote will be merged-forward by SaltStack core engineers and
the new tests will propagate to the newer release branches. That way the tests you
wrote will apply to all current and relevant release branches, and not just the ``develop``
wrote will apply to all current and relevant release branches, and not just the ``|repo_primary_branch|``
branch, for example. This methodology will help protect against regressions on older
files in Salt's codebase.

16
doc/topics/development/tutorial.rst
View file

@ -48,21 +48,21 @@ completed, add SaltStack as a second remote and fetch any changes from
$ git remote add upstream https://github.com/saltstack/salt.git
$ git fetch upstream
For this tutorial, we will be working off from the ``develop`` branch, which is
For this tutorial, we will be working off from the ``|repo_primary_branch|`` branch, which is
the default branch for the SaltStack GitHub project. This branch needs to
track ``upstream/develop`` so that we will get all upstream changes when they
track ``upstream/|repo_primary_branch|`` so that we will get all upstream changes when they
happen.
.. code-block:: bash
$ git checkout develop
$ git branch --set-upstream-to upstream/develop
$ git checkout |repo_primary_branch|
$ git branch --set-upstream-to upstream/|repo_primary_branch|
-----
Fetch
-----
Fetch any ``upstream`` changes on the ``develop`` branch and sync them to your
Fetch any ``upstream`` changes on the ``|repo_primary_branch|`` branch and sync them to your
local copy of the branch with a single command:
.. code-block:: bash
@ -84,7 +84,7 @@ Now we are ready to get to work. Consult the `sprint beginner bug list
and select an execution module whose ``__virtual__`` function needs to be
updated. I'll select the ``alternatives`` module.
Create a new branch off from ``develop``. Be sure to name it something short
Create a new branch off from ``|repo_primary_branch|``. Be sure to name it something short
and descriptive.
.. code-block:: bash
@ -173,7 +173,7 @@ In your browser, navigate to the `new pull request
<https://github.com/saltstack/salt/compare>`_ page on the ``saltstack/salt``
GitHub repository and click on ``compare across forks``. Select
``<my_account>`` from the list of head forks and the branch you are wanting to
merge into ``develop`` (``virt_ret`` in this case).
merge into ``|repo_primary_branch|`` (``virt_ret`` in this case).
When you have finished reviewing the changes, click ``Create pull request``.
@ -194,7 +194,7 @@ request``.
* I find it easiest to edit the following URL:
``https://github.com/saltstack/salt/compare/develop...<my_account>:virt_ret``
``https://github.com/saltstack/salt/compare/|repo_primary_branch|...<my_account>:virt_ret``
---------
Resources

2
doc/topics/installation/windows.rst
View file

@ -265,7 +265,7 @@ customize or fix bugs. It will also allow you to build your own installation.
There are several scripts to automate creating a Windows installer as well as
setting up an environment that facilitates developing and troubleshooting Salt
code. They are located in the ``pkg\windows`` directory in the Salt repo
`(here) <https://github.com/saltstack/salt/tree/develop/pkg/windows>`_.
`(here) <https://github.com/saltstack/salt/tree/|repo_primary_branch|/pkg/windows>`_.
Scripts:
--------

10
doc/topics/pillar/index.rst
View file

@ -741,11 +741,11 @@ done:
option in the `master config template`_ should be updated to show the correct
new default value.
.. _`salt/renderers/`: https://github.com/saltstack/salt/tree/develop/salt/renderers/
.. _`salt/config/__init__.py`: https://github.com/saltstack/salt/tree/develop/salt/config/__init__.py
.. _`master config file`: https://github.com/saltstack/salt/tree/develop/doc/ref/configuration/master.rst
.. _`minion config file`: https://github.com/saltstack/salt/tree/develop/doc/ref/configuration/minion.rst
.. _`master config template`: https://github.com/saltstack/salt/tree/develop/conf/master
.. _`salt/renderers/`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/renderers/
.. _`salt/config/__init__.py`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/config/__init__.py
.. _`master config file`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/doc/ref/configuration/master.rst
.. _`minion config file`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/doc/ref/configuration/minion.rst
.. _`master config template`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/conf/master
Binary Data in the Pillar
=========================