-
Notifications
You must be signed in to change notification settings - Fork 51
Development Environment
Salt's source code is managed via Git. Basic Git knowledge is assumed, but we have examples of somewhat advanced Git workflows in our Common Workflows section.
This repository is not the authoritative Salt repository. As such, openSUSE's Salt developers need to work with multiple Git Remotes:
-
https://github.com/saltstack/salt -
origin
-
https://github.com/openSUSE/salt -
opensuse
-
https://github.com/<geeko>/salt -
geeko
(created by forkingorigin
) -
https://github.com/<geeko>/salt-1 -
opensuse-fork
(created by forkingopensuse
after setting up remotegeeko
)
You can choose these names
freely, however, this documentation will use the names that are listed above.
A local checkup with the remote setup, once the forks are created through GitHub, can easily be done with a few git
commands.
cd ~/src # optional
geeko=agraul
git clone [email protected]:saltstack/salt salt && cd $_
git remote add opensuse [email protected]:openSUSE/salt
git remote add $geeko [email protected]:$geeko/salt
git remote add opensuse-fork [email protected]:$geeko/salt-1
git fetch --all
On origin
, the only branch we work with is master
. On opensuse
however, we maintain a branch for each Salt version we package and support:
-
openSUSE/release/3006.0
(default branch)
The default branch is the one of the current version in the latest openSUSE Leap and SUSE Linux Enterprise.
New branches are created by rebasing older patches on top of an origin
Salt release (marked by a Git tag). From then on, they move independently with us backporting bug fixes from newer releases.
To reduce the number of branches we have on the top level we do want to make use of folders. Folders for Git branches is a concept which many popular Git GUIs implement and it eases the overview in case you have a lot of branches.
The naming schema we follow can be observed in the following list:
master --> saltstack/salt master branch
fix/<name> --> Upstream fixes
openSUSE/release/<name> --> Downstream openSUSE release
openSUSE/fix/<name> --> openSUSE specific fixes
openSUSE/backport/<name> --> openSUSE specific backports
openSUSE/MU/<release> --> SUMA MU versions
<name> --> features and misc
Note: At this point in time the openSUSE/salt repository does not have the fork relationship for saltstack/salt. We will readd this after SUSE Manager 4.3 GA was tagged.
There are generally two reasons for opening a Pull Request: adding a new feature or fixing a bug in the existing code base. In both cases, Pull Requests in this repo (opensuse
) must point to one or more Pull Request(s) upstream (@origin
).
Pull Requests @origin
must have received positive feedback or been merged before they can be accepted. If origin
does not agree with a bug fix, try to find a different way that solves the bug. We don't want to carry changes that are not accepted into origin
.
One useful Git feature is git-worktree
which allows multiple work trees to co-exist. Different work trees must have different branches checked out and can be used for quickly jumping between Salt versions without having to git stash
or git commit
first.
For example, you might have two long living git trees you work on: one that has origin
's master branch checked out and one for opensuse
's default branch:
# tree -L 1 ~/src/salt
├── 3002
└── master
Virtual environments (venvs) are isolated environments that can be used to keep all Python packages needed for developing Salt in one place. They help avoiding conflicts with globally installed Python packages, e.g. when two Python programs need different versions of the same package.
With the following steps you can create a git checkout of the Salt repository and a virtual environment called venv
inside of it.
Step 5 installs Salt's dependencies into the virtual environment. Some of these need additional system libraries. On openSUSE Leap or Tumbleweed, you can install them with zypper install python3-devel libopenssl-devel libcurl-devel zeromq-devel
git clone https://github.com/saltstack/salt salt && cd $_
-
python3 -m venv venv
# the firstvenv
is the virtual environment module, the secondvenv
is the name of the virtual environment. . venv/bin/activate
-
python --version
# Verify the virtual environment is set up and active,python
should invokepython3
now python -m pip install -r requirements/base.txt -r requirements/pytest.txt -r requirements/crypto.txt -r requirements/zeromq.txt
- (Optional)
python -m pip install nox
# needed for running tests - Hack, hack, hack
deactivate