rpms/leapp
5
0
Fork 0
Code Issues Pull Requests Releases Activity
c8
leapp/SOURCES/0001-Update-references-from-master-branch-to-main.patch

526 lines
33 KiB
Diff
Raw Permalink Normal View History

Import from CS git
2024-11-25 09:10:02 +00:00
From 97871166d037fce1029428d369541ec2d6eeeef7 Mon Sep 17 00:00:00 2001
From: Vojtech Sokol <vsokol@redhat.com>
Date: Mon, 2 Sep 2024 17:22:11 +0200
Subject: [PATCH 1/6] Update references from master branch to main
Focus was on making the CI and GitHub actions work after the default
branch was switched from master to main.
See: OAMG-4907
---
.github/workflows/pr-welcome-msg.yml | 4 ++--
.github/workflows/reuse-copr-build.yml | 4 ++--
.github/workflows/unit-tests.yml | 10 +++++-----
.packit.yaml | 6 +++---
Makefile | 8 ++++----
docs/source/best-practices.md | 20 +++++++++----------
docs/source/build-schema.md | 4 ++--
.../compatibility-with-leapp-repository.md | 2 +-
docs/source/contributing.md | 6 +++---
docs/source/dependencies-leapp-repository.md | 8 ++++----
docs/source/dependencies.md | 2 +-
docs/source/deprecation.md | 2 +-
docs/source/devenv-install.md | 4 ++--
docs/source/el7toel8/actor-rhel7-to-rhel8.md | 12 +++++------
.../source/el7toel8/inhibit-rhel7-to-rhel8.md | 4 ++--
docs/source/test-actors.md | 4 ++--
docs/source/unit-testing.md | 8 ++++----
packaging/leapp.spec | 4 ++--
18 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/.github/workflows/pr-welcome-msg.yml b/.github/workflows/pr-welcome-msg.yml
index af5d543..66d001e 100644
--- a/.github/workflows/pr-welcome-msg.yml
+++ b/.github/workflows/pr-welcome-msg.yml
@@ -25,9 +25,9 @@ jobs:
- **/packit copr-build** to submit a public copr build using packit
To launch regression testing public members of oamg organization can leave the following comment:
- - **/rerun** to schedule basic regression tests using this pr build and leapp-repository\*master\* as artifacts
+ - **/rerun** to schedule basic regression tests using this pr build and leapp-repository\*main\* as artifacts
- **/rerun 42** to schedule basic regression tests using this pr build and leapp-repository\*PR42\* as artifacts
- - **/rerun-sst** to schedule sst tests using this pr build and leapp-repository\*master\* as artifacts
+ - **/rerun-sst** to schedule sst tests using this pr build and leapp-repository\*main\* as artifacts
- **/rerun-sst 42** to schedule sst tests using this pr build and leapp-repository\*PR42\* as artifacts
Please [open ticket](https://url.corp.redhat.com/oamg-ci-issue) in case you experience technical problem with the CI. (RH internal only)
diff --git a/.github/workflows/reuse-copr-build.yml b/.github/workflows/reuse-copr-build.yml
index a935c7e..b0079a1 100644
--- a/.github/workflows/reuse-copr-build.yml
+++ b/.github/workflows/reuse-copr-build.yml
@@ -59,7 +59,7 @@ jobs:
echo "::set-output name=sha::$(git rev-parse --short HEAD)"
echo "::set-output name=ref::refs/pull/${{ steps.pr_nr.outputs.pr_nr }}/head"
- - name: Get latest leapp-repository master copr build id
+ - name: Get latest leapp-repository main copr build id
id: get_latest_lpr_copr_build_id
if: ${{ steps.leapp_repository_pr_regex_match.outputs.match == '' }}
run: |
@@ -73,7 +73,7 @@ jobs:
EOF
pip install copr-cli
- REGEX='leapp-repository.*master.*' COPR_REPO='@oamg/leapp' _COPR_CONFIG=copr_fedora.conf python ${{ github.workspace }}/utils/get_latest_copr_build > latest_lpr
+ REGEX='leapp-repository.*main.*' COPR_REPO='@oamg/leapp' _COPR_CONFIG=copr_fedora.conf python ${{ github.workspace }}/utils/get_latest_copr_build > latest_lpr
COPR_ID=$(cat latest_lpr)
echo "::set-output name=copr_id::${COPR_ID##*/}"
diff --git a/.github/workflows/unit-tests.yml b/.github/workflows/unit-tests.yml
index e67264b..a0a3942 100644
--- a/.github/workflows/unit-tests.yml
+++ b/.github/workflows/unit-tests.yml
@@ -2,10 +2,10 @@ name: Unit Tests
on:
push:
branches:
- - master
+ - main
pull_request:
branches:
- - master
+ - main
jobs:
test:
@@ -33,9 +33,9 @@ jobs:
uses: actions/checkout@v4
with:
fetch-depth: '0'
- - name: Set master to origin/master
- if: github.ref != 'refs/heads/master'
+ - name: Set main to origin/main
+ if: github.ref != 'refs/heads/main'
run: |
- git branch -f master origin/master
+ git branch -f main origin/main
- name: ${{matrix.scenarios.name}}
run: script -e -c /bin/bash -c 'TERM=xterm podman build --security-opt=seccomp=unconfined -t leapp-tests -f res/container-tests/Containerfile.${{matrix.scenarios.container}} res/container-tests && PYTHON_VENV=${{matrix.scenarios.python}} REPOSITORIES=${{matrix.scenarios.repos}} podman run --security-opt=seccomp=unconfined --rm -ti -v ${PWD}:/payload --env=PYTHON_VENV --env=REPOSITORIES leapp-tests'
diff --git a/.packit.yaml b/.packit.yaml
index 2aead86..36a6e16 100644
--- a/.packit.yaml
+++ b/.packit.yaml
@@ -19,7 +19,7 @@ jobs:
- fedora-all-x86_64
actions:
post-upstream-clone:
- # builds from PRs should have lower NVR than those from master branch
+ # builds from PRs should have lower NVR than those from main branch
- sed -i "s/1%{?dist}/0%{?dist}/g" packaging/leapp.spec
get-current-version:
# get version from spec file instead from git tag
@@ -27,7 +27,7 @@ jobs:
- job: copr_build
trigger: commit
metadata:
- branch: master
+ branch: main
owner: "@oamg"
project: leapp
targets:
@@ -38,7 +38,7 @@ jobs:
- fedora-all-x86_64
actions:
post-upstream-clone:
- # builds from master branch should have the highest NVR
+ # builds from main branch should have the highest NVR
- sed -i "s/1%{?dist}/100%{?dist}/g" packaging/leapp.spec
get-current-version:
# get version from spec file instead from git tag
diff --git a/Makefile b/Makefile
index 677c748..0c1b805 100644
--- a/Makefile
+++ b/Makefile
@@ -23,7 +23,7 @@ _TEST_CONTAINER=$${TEST_CONTAINER:-rhel8}
# just to reduce number of unwanted builds mark as the upstream one when
# someone will call copr_build without additional parameters
-MASTER_BRANCH=master
+MASTER_BRANCH=main
# In case the PR or MR is defined or in case build is not coming from the
# MATER_BRANCH branch, N_REL=0; (so build is not update of the approved
@@ -44,14 +44,14 @@ REQUEST=`if test -n "$$PR"; then echo ".PR$${PR}"; elif test -n "$$MR"; then ech
# Examples:
# 0.201810080027Z.4078402.packaging.PR2
# 0.201810080027Z.4078402.packaging
-# 0.201810080027Z.4078402.master.MR2
-# 1.201810080027Z.4078402.master
+# 0.201810080027Z.4078402.main.MR2
+# 1.201810080027Z.4078402.main
RELEASE="$(N_REL).$(TIMESTAMP).$(SHORT_SHA).$(BRANCH)$(REQUEST)$(_SUFFIX)"
ifneq ($(shell id -u),0)
ENTER_VENV := . $(VENVNAME)/bin/activate;
else
- ENTER_VENV :=
+ ENTER_VENV :=
endif
all: help
diff --git a/docs/source/best-practices.md b/docs/source/best-practices.md
index f3387e2..46aedbc 100644
--- a/docs/source/best-practices.md
+++ b/docs/source/best-practices.md
@@ -43,17 +43,17 @@ to a shared library function. You can introduce it in one of these two places:
writing your actor for, e.g. for an OS in-place upgrade workflow, should go to the `<Leapp repository>/libraries`
folder. In this case, we welcome your proposals under the
[leapp-repository on GitHub](https://github.com/oamg/leapp-repository).
-
+
Please note that the name of the library module in this case should be unique and contain
the actor name. For example:
`repos/system_upgrade/el7toel8/actors/vimmigrate/libraries/vimmigrate.py`
-
+
## Discover standard library functions
Before implementing functionality for your actor, browse through the available functionality provided by:
-- the [Leapp Standard Library](https://github.com/oamg/leapp/tree/master/leapp/libraries/stdlib/),
+- the [Leapp Standard Library](https://github.com/oamg/leapp/tree/main/leapp/libraries/stdlib/),
- the shared library of your Leapp repository (`<Leapp repository>/libraries` folder).
These libraries contain functions that may satisfy your needs. Using them can save you time, lower code complexity and
@@ -63,7 +63,7 @@ help avoiding duplicate code. Improvement proposals for the library functions ar
Sources of external functionality to be used in your actor in order of preference:
-1. the [Leapp Standard Library](https://github.com/oamg/leapp/tree/master/leapp/libraries/stdlib/)
+1. the [Leapp Standard Library](https://github.com/oamg/leapp/tree/main/leapp/libraries/stdlib/)
2. the [Python Standard Library](https://docs.python.org/3/library/index.html)
3. shell commands
@@ -81,13 +81,13 @@ As with the Leapp Standard Library mentioned above, it may be beneficial for you
place in the [leapp-repository](https://github.com/oamg/leapp-repository). You might be interested in the messages they
produce, for example:
-- [SystemFactsActor](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/actors/systemfacts/actor.py) -
+- [SystemFactsActor](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/actors/systemfacts/actor.py) -
information about kernel modules, yum repos, sysctl variables, users, firewall, SELinux, etc.
-- [OSReleaseCollector](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/actors/osreleasecollector/actor.py) -
+- [OSReleaseCollector](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/actors/osreleasecollector/actor.py) -
system release information
-- [RpmScanner](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/actors/rpmscanner/actor.py) -
+- [RpmScanner](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/actors/rpmscanner/actor.py) -
list of installed packages
-- [StorageScanner](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/actors/storagescanner/actor.py) -
+- [StorageScanner](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/actors/storagescanner/actor.py) -
storage information
In case you find any message of the existing actors to be incorrect, incomplete or misleading, we encourage you to
@@ -123,8 +123,8 @@ For more about unit testing, see the [tutorial](unit-testing).
## Do not introduce new dependencies
Ideally, actors shouldn't require any additional dependency on top of the dependencies already in the
-[leapp](https://github.com/oamg/leapp/blob/master/packaging/leapp.spec) and
-[leapp-repository](https://github.com/oamg/leapp-repository/blob/master/packaging/leapp-repository.spec) spec files,
+[leapp](https://github.com/oamg/leapp/blob/main/packaging/leapp.spec) and
+[leapp-repository](https://github.com/oamg/leapp-repository/blob/main/packaging/leapp-repository.spec) spec files,
which are, as of December 2018, just these:
- dnf
diff --git a/docs/source/build-schema.md b/docs/source/build-schema.md
index 053ff0c..7919964 100644
--- a/docs/source/build-schema.md
+++ b/docs/source/build-schema.md
@@ -4,7 +4,7 @@ All projects under the OAMG should use the same schema for names of RPM builds,
to be able to simply and fast find specific builds. The schema itself looks
like that (NVR without %{dist}):
-- for builds made from the master branch:
+- for builds made from the main branch:
```
<name>-<version>-100.<timestamp>.<short-hash>.<branch>
```
@@ -25,4 +25,4 @@ Where:
of a (S)RPM file; so it is suggested (not required) to to avoid dashes
in names of branches
- **number** is number of a pull-request (alternatively merge-request) to which
- builds are related
\ No newline at end of file
+ builds are related
diff --git a/docs/source/compatibility-with-leapp-repository.md b/docs/source/compatibility-with-leapp-repository.md
index 40441ed..13c6123 100644
--- a/docs/source/compatibility-with-leapp-repository.md
+++ b/docs/source/compatibility-with-leapp-repository.md
@@ -9,7 +9,7 @@ We rather prefer releasing new versions with changelogs and everything
when we agree it's worthwhile.
But we need a mechanism to be able to synchronize with other projects, when we
-provide new functionality in the upstream (master) branch without the need
+provide new functionality in the upstream (main) branch without the need
of immediate release of the new version of leapp. For these purposes the
`leapp-framework` capability is provided in the framework (python[23]-leapp) rpms.
diff --git a/docs/source/contributing.md b/docs/source/contributing.md
index f0422ee..65f94a5 100644
--- a/docs/source/contributing.md
+++ b/docs/source/contributing.md
@@ -29,7 +29,7 @@ Before you submit your pull request, consider the following guidelines:
* Fork the repository and clone your fork.
* Make your changes in a new git branch:
- ``git checkout -b bug/my-fix-branch master``
+ ``git checkout -b bug/my-fix-branch main``
* Include documentation that either describe a change to a behavior or the changed capability to an end user.
* Commit your changes with message conforming to the [Git Commit Messages](#git-commit-messages) guidelines.
@@ -39,7 +39,7 @@ Before you submit your pull request, consider the following guidelines:
``git push --set-upstream origin bug/my-fix-branch``
-* When opening a pull request, select the `master` branch as a base.
+* When opening a pull request, select the `main` branch as a base.
* Mark your pull request with **[WIP]** (Work In Progress) to get feedback, but prevent merging (for example,
[WIP] Update CONTRIBUTING.rst).
* If you are fixing a GitHub issue, include the issue number you are fixing, e.g. 'Closes issue #xyz'.
@@ -51,7 +51,7 @@ Before you submit your pull request, consider the following guidelines:
* Push changes to git (this will update your pull request). For that you can add a new commit or rebase your branch
and force push to your GitHub repository like this: ::
- git rebase -i master
+ git rebase -i main
git push -f origin bug/my-fix-branch
### Merge Rules
diff --git a/docs/source/dependencies-leapp-repository.md b/docs/source/dependencies-leapp-repository.md
index dc0ed61..cbefca0 100644
--- a/docs/source/dependencies-leapp-repository.md
+++ b/docs/source/dependencies-leapp-repository.md
@@ -14,11 +14,11 @@ this document focuses on the leapp-repository specifics only.
Currently there are two SPEC files for leapp-repository:
- The
-[leapp-repository.spec](https://github.com/oamg/leapp-repository/blob/master/packaging/leapp-repository.spec)
+[leapp-repository.spec](https://github.com/oamg/leapp-repository/blob/main/packaging/leapp-repository.spec)
file is used to build leapp-repository packages and their dependency
metapackage _leapp-repository-deps_ **for RHEL 7**.
- The
-[leapp-el7toel8-deps.spec](https://github.com/oamg/leapp-repository/blob/master/packaging/leapp-el7toel8-deps.spec)
+[leapp-el7toel8-deps.spec](https://github.com/oamg/leapp-repository/blob/main/packaging/leapp-el7toel8-deps.spec)
file is used to build dependency metapackages _leapp-deps-el8_ and
_leapp-repository-deps-el8_ **for RHEL 8** whose purpose is to replace the
RHEL 7 dependency metapackages _leapp-deps_ and _leapp-repository-deps_ during
@@ -27,10 +27,10 @@ the upgrade.
## What to do in leapp-repository when dependencies of leapp change?
Go to the section below the line `%package -n %{ldname}` in the
-[leapp-el7toel8-deps.spec](https://github.com/oamg/leapp-repository/blob/master/packaging/leapp-el7toel8-deps.spec).
+[leapp-el7toel8-deps.spec](https://github.com/oamg/leapp-repository/blob/main/packaging/leapp-el7toel8-deps.spec).
This section creates the RHEL 8 _leapp-deps-el8_ metapackage that replaces the
RHEL7 _leapp-deps_ metapackage. So when the leapp package dependencies change
-in the [leapp.spec](https://github.com/oamg/leapp/blob/master/packaging/leapp.spec)
+in the [leapp.spec](https://github.com/oamg/leapp/blob/main/packaging/leapp.spec)
together with incrementing version of the **leapp-framework-dependencies**
capability, it's necessary to:
diff --git a/docs/source/dependencies.md b/docs/source/dependencies.md
index a94beab..9d0fdca 100644
--- a/docs/source/dependencies.md
+++ b/docs/source/dependencies.md
@@ -40,7 +40,7 @@ As a solution, we are using the metapackage that contains those dependencies.
## What to do when dependencies needs to be changed
It's easy to change *outer dependencies* for Leapp. Open the
-[packaging/leapp.spec](https://github.com/oamg/leapp/blob/master/packaging/leapp.spec) file and change the dependencies as needed under
+[packaging/leapp.spec](https://github.com/oamg/leapp/blob/main/packaging/leapp.spec) file and change the dependencies as needed under
`%package deps`. The right place is pretty highlighted (you cannot miss it):
```spec
diff --git a/docs/source/deprecation.md b/docs/source/deprecation.md
index b583758..65cc18a 100644
--- a/docs/source/deprecation.md
+++ b/docs/source/deprecation.md
@@ -10,7 +10,7 @@ impact on your code, we introduce the deprecation process described below.
The following lists cover deprecated functionality in the leapp utility, snactor,
the leapp standard library, etc. But don't cover deprecated functionalities
-from particular leapp repositories (e.g. the [elt7toel8](https://github.com/oamg/leapp-repository/tree/master/repos/system_upgrade/el7toel8) leapp repository). For
+from particular leapp repositories (e.g. the [elt7toel8](https://github.com/oamg/leapp-repository/tree/main/repos/system_upgrade/el7toel8) leapp repository). For
such information, see [Deprecated functionality in the el7toel8 repository](el7toel8/deprecation.html#deprecated-functionality-in-the-el7toel8-repository).
## current upstream development <span style="font-size:0.5em; font-weight:normal">(till the next release + 6months)</span>
diff --git a/docs/source/devenv-install.md b/docs/source/devenv-install.md
index 72f2590..84a5bab 100644
--- a/docs/source/devenv-install.md
+++ b/docs/source/devenv-install.md
@@ -4,7 +4,7 @@
If you do not want to modify the framework itself, install it from
the RPM packages provided by the [Copr](https://copr.fedorainfracloud.org/coprs/g/oamg/leapp/)
-build system, which automatically builds packages with every commit merged into master.
+build system, which automatically builds packages with every commit merged into main.
Packages are built for EPEL and Fedora.
* On CentOS/RHEL:
@@ -65,7 +65,7 @@ Optional arguments:
--debug Enables debug mode
Main commands:
-
+
new-tag Create a new tag
new-model Creates a new model
run Execute the given actor
diff --git a/docs/source/el7toel8/actor-rhel7-to-rhel8.md b/docs/source/el7toel8/actor-rhel7-to-rhel8.md
index 06bdfae..2cc72f3 100644
--- a/docs/source/el7toel8/actor-rhel7-to-rhel8.md
+++ b/docs/source/el7toel8/actor-rhel7-to-rhel8.md
@@ -21,7 +21,7 @@ The leapp framework provides the libraries required to be imported by any actor
Separate tool provided by Leapp to help the process of creating and executing an actor.
-You can see _snactor_ source code [here](https://github.com/oamg/leapp/tree/master/leapp/snactor).
+You can see _snactor_ source code [here](https://github.com/oamg/leapp/tree/main/leapp/snactor).
## Creating an actor
@@ -62,7 +62,7 @@ For further information about how create an actor read this [document](../first-
Until now, you have created boilerplate of a new actor and made it visible to Leapp. But, Leapp needs some more information about what to do with the actor. Specifically, in which **“workflow”** and in which **“phase”** the actor should be executed. A workflow is a sequence of phases. The only workflow available now is the one solving the upgrade of RHEL 7 to RHEL 8. Each phase is a set of actors that will be executed one after another before the next phase starts. To find out in which workflow and phase should the actor be executed, Leapp looks for **“tags”**. To be part of RHEL 7 to RHEL 8 upgrade workflow, an actor needs to be tagged with **IPUWorkflowTag**.
-The phases of the IPUWorkflow (in order) are: **Facts Collection, Checks, Report, Download, Upgrade RamDisk Preparation, Upgrade RamDisk Start, Late Tests, Preparation, RPM Upgrade, Application Upgrade, Third Party Applications, Finalization** and **First Boot**. Each phase has a specific tag that marks an actor as being part of that phase. You can find descriptions of all the phases and their tags [here](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/common/workflows/inplace_upgrade.py) and workflow diagram [here](../inplace-upgrade-workflow).
+The phases of the IPUWorkflow (in order) are: **Facts Collection, Checks, Report, Download, Upgrade RamDisk Preparation, Upgrade RamDisk Start, Late Tests, Preparation, RPM Upgrade, Application Upgrade, Third Party Applications, Finalization** and **First Boot**. Each phase has a specific tag that marks an actor as being part of that phase. You can find descriptions of all the phases and their tags [here](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/common/workflows/inplace_upgrade.py) and workflow diagram [here](../inplace-upgrade-workflow).
For example, if an actor is to be executed within the Checks phase, it needs to be tagged both with IPUWorkflowTag and ChecksPhaseTag. The result after updating the boilerplate would be:
@@ -90,7 +90,7 @@ All communication between actors in Leapp is carried out using **“messages”*
For further information about messaging see [document](../messaging).
-One of the existing models in Leapp is [ActiveKernelModulesFacts](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/models/activekernelmodulesfacts.py). Messages from this model contain data about the system on which Leapp has been started. For example, it contains installed kernel modules. If an actor wants to perform some action based on existing kernel modules on the system, the actor can get list of these modules by consuming the _ActiveKernelModulesFacts_ messages. By extending the boilerplate, the code could look like this:
+One of the existing models in Leapp is [ActiveKernelModulesFacts](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/models/activekernelmodulesfacts.py). Messages from this model contain data about the system on which Leapp has been started. For example, it contains installed kernel modules. If an actor wants to perform some action based on existing kernel modules on the system, the actor can get list of these modules by consuming the _ActiveKernelModulesFacts_ messages. By extending the boilerplate, the code could look like this:
```python
from leapp.actors import Actor
@@ -280,7 +280,7 @@ During development of your new actor, it is expected that you will test your wor
### Executing a single actor
-You should use snactor tool to run a single actor and verify its output. Assuming that there are no errors, the actor was placed inside a valid leapp repository and snactor tool is aware of such repository, you can call snactor run to execute it. Below we are executing the existing [OSReleaseCollector](https://github.com/oamg/leapp-repository/tree/master/repos/system_upgrade/el7toel8/actors/osreleasecollector) actor that provides information about operating system release from target system. For the `snactor run` command you can use either the actor’s folder name (osreleasecollector), the actor’s class name (OSReleaseCollector) or the value of the name attribute of the actor’s class (os_release_collector).
+You should use snactor tool to run a single actor and verify its output. Assuming that there are no errors, the actor was placed inside a valid leapp repository and snactor tool is aware of such repository, you can call snactor run to execute it. Below we are executing the existing [OSReleaseCollector](https://github.com/oamg/leapp-repository/tree/main/repos/system_upgrade/el7toel8/actors/osreleasecollector) actor that provides information about operating system release from target system. For the `snactor run` command you can use either the actor’s folder name (osreleasecollector), the actor’s class name (OSReleaseCollector) or the value of the name attribute of the actor’s class (os_release_collector).
```shell
# pwd
@@ -350,7 +350,7 @@ Finally, you can make your actor part of the “leapp upgrade” process and che
### Verifying correct communication between actors
-Leapp provides another actor, named [CheckOSRelease](https://github.com/oamg/leapp-repository/tree/master/repos/system_upgrade/el7toel8/actors/checkosrelease), that consumes messages from model _OSReleaseFacts_ and produces an error message in case system OS Release is not supported by Leapp upgrade process. In order to consume such message, _OSReleaseCollector_ actor needs to be executed before _CheckOSRelease_ and its message needs to be stored inside Leapp database. This process is controlled by the framework during the execution of “leapp upgrade” command.
+Leapp provides another actor, named [CheckOSRelease](https://github.com/oamg/leapp-repository/tree/main/repos/system_upgrade/el7toel8/actors/checkosrelease), that consumes messages from model _OSReleaseFacts_ and produces an error message in case system OS Release is not supported by Leapp upgrade process. In order to consume such message, _OSReleaseCollector_ actor needs to be executed before _CheckOSRelease_ and its message needs to be stored inside Leapp database. This process is controlled by the framework during the execution of “leapp upgrade” command.
But, if you want to execute it manually, for test purposes, you can also use snactor for it. First we need to make sure that all messages that will be consumed are generated and stored. For this example, this means running _OSReleaseCollector_ actor with the _--save-output_ option of snactor:
@@ -412,7 +412,7 @@ This [pull request](https://github.com/oamg/leapp-repository/pull/186) gives a g
### In which existing workflow phase should I place my new actor?
-You can decide that based on the description of the phases this information is available in the [code](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/workflows/inplace_upgrade.py) and diagram [here](../inplace-upgrade-workflow). Please note that if your actor depends on some message generated by another actor, it cannot be executed in a phase before the phase of such actor. In a similar way, if your actor produces data, it needs to be executed before the actor consuming the data.
+You can decide that based on the description of the phases this information is available in the [code](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/workflows/inplace_upgrade.py) and diagram [here](../inplace-upgrade-workflow). Please note that if your actor depends on some message generated by another actor, it cannot be executed in a phase before the phase of such actor. In a similar way, if your actor produces data, it needs to be executed before the actor consuming the data.
### How to stop the upgrade in case my actor finds a problem with the system setup?
diff --git a/docs/source/el7toel8/inhibit-rhel7-to-rhel8.md b/docs/source/el7toel8/inhibit-rhel7-to-rhel8.md
index 5e97c78..a31208f 100644
--- a/docs/source/el7toel8/inhibit-rhel7-to-rhel8.md
+++ b/docs/source/el7toel8/inhibit-rhel7-to-rhel8.md
@@ -56,7 +56,7 @@ $ snactor run CheckSystemArch --verbose
If, instead of only adding a message to the log, the actor writer wants to make
sure that the upgrade process will be stopped in case of unsupported arch, the
actor needs to produce a [Report](/pydoc/leapp.reporting.html#leapp.reporting.Report)
-message using one of the `report_*` functions from the [reporting](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/libraries/reporting.py)
+message using one of the `report_*` functions from the [reporting](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/libraries/reporting.py)
shared library with the `'inhibitor'` group.
```python
@@ -131,7 +131,7 @@ This is all that an actor needs to do in order to verify if some condition is
present on the system and inhibit the upgrade process based on that check.
After all the system checks are executed by different actors, an existing actor
-named [VerifyCheckResults](https://github.com/oamg/leapp-repository/tree/master/repos/system_upgrade/el7toel8/actors/verifycheckresults)
+named [VerifyCheckResults](https://github.com/oamg/leapp-repository/tree/main/repos/system_upgrade/el7toel8/actors/verifycheckresults)
is scheduled to run in the Leapp upgrade workflow. If some [Report](/pydoc/leapp.reporting.html#leapp.reporting.Report)
message with the `'inhibitor'` group was generated by some previous execution of
another actor in any previous phase of the workflow, like the sample one we just
diff --git a/docs/source/test-actors.md b/docs/source/test-actors.md
index 322fe77..967c2ad 100644
--- a/docs/source/test-actors.md
+++ b/docs/source/test-actors.md
@@ -21,13 +21,13 @@ Test module names should match the following regex:
- These tests deal with individual actor's functions/methods.
- It's not possible to unit test any method/function within the *actor.py*. You can write unit tests only for functions/methods within the actor's libraries.
- Thus, to be able to write unit tests for an actor, ideally the only thing in the _actor.py_'s _process()_ method is calling the entry-point function of the actor's library python module.
-- [Example of unit tests](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/actors/checkbootavailspace/tests/unit_test_checkbootavailspace.py)
+- [Example of unit tests](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/actors/checkbootavailspace/tests/unit_test_checkbootavailspace.py)
### Component tests
- These tests provide fabricated input messages for the actor, check the outputs stated in the actor's description.
- These tests should not be written based on the actor's code but rather based on the behavior stated in the actor's description. They could be written by somebody who didn't write the code.
-- [Example of component tests](https://github.com/oamg/leapp-repository/blob/master/repos/system_upgrade/el7toel8/actors/checknfs/tests/test_checknfs.py)
+- [Example of component tests](https://github.com/oamg/leapp-repository/blob/main/repos/system_upgrade/el7toel8/actors/checknfs/tests/test_checknfs.py)
## End to end (e2e) tests
diff --git a/docs/source/unit-testing.md b/docs/source/unit-testing.md
index d4feec9..52310e1 100644
--- a/docs/source/unit-testing.md
+++ b/docs/source/unit-testing.md
@@ -11,7 +11,7 @@ Tests are considered being part of the actor and we do not only encourage but
basically require you to write tests if you want the actors to be accepted into
the git repository. To read more about what we ask from you when submitting
your work for our review, see
-[Contributing guidelines for writing actors](https://github.com/oamg/leapp-repository/blob/master/CONTRIBUTING.md).
+[Contributing guidelines for writing actors](https://github.com/oamg/leapp-repository/blob/main/CONTRIBUTING.md).
Tests for an actor are to be placed within the actor's directory, in a
subdirectory called `tests`. The layout for an actor `MyActor` in the
@@ -111,7 +111,7 @@ supposed to be unit tested is necessary to move into the actor's private
library. Modules from the private library can then be imported not only from
the `actor.py` but also from the test modules.
-Let's assume your actor has a private library module called
+Let's assume your actor has a private library module called
`private_{actor_name}.py`.
```
@@ -173,7 +173,7 @@ install-deps:
Note: Dependencies defined the way mentioned above is for test execution only.
If your actor requires any package when executed as part of a workflow, it
needs to be specified in a
-[leapp-repository specfile](https://github.com/oamg/leapp-repository/blob/master/packaging/leapp-repository.spec).
+[leapp-repository specfile](https://github.com/oamg/leapp-repository/blob/main/packaging/leapp-repository.spec).
## Running the tests
@@ -209,7 +209,7 @@ It is also possible to run only selected tests based on their name:
pytest -k "vim" # to run all tests contains vim in name
pytest -k "not vim" # to run all tests, which not contains vim in name
```
-More examples could be found in the
+More examples could be found in the
[pytest documentation](https://docs.pytest.org/en/latest/example/markers.html#using-k-expr-to-select-tests-based-on-their-name)
### Shared libraries' tests
diff --git a/packaging/leapp.spec b/packaging/leapp.spec
index 2352bf0..ab38d20 100644
--- a/packaging/leapp.spec
+++ b/packaging/leapp.spec
@@ -1,9 +1,9 @@
# IMPORTANT:
# Please read the documentation on how to deal with dependencies before adding a new one.
-# https://github.com/oamg/leapp/blob/master/docs/source/dependencies.md
+# https://github.com/oamg/leapp/blob/main/docs/source/dependencies.md
%global debug_package %{nil}
-%global gittag master
+%global gittag main
# IMPORTANT: this is for the leapp-framework capability (it's not the real
# version of the leapp). The capability reflects changes in api and whatever
--
2.47.0
Reference in New Issue Copy Permalink