diff --git a/.github/workflows/pr-welcome-msg.yml b/.github/workflows/pr-welcome-msg.yml index af5d543f4..66d001eb1 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 a935c7e37..b0079a165 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 e67264be7..a0a394215 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 2aead8640..36a6e165d 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 677c74806..0c1b80587 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 f3387e2dd..46aedbc54 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 `/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 (`/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 053ff0c76..79199646f 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: ``` --100... ``` @@ -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 40441ed10..13c61233e 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 f0422ee8e..65f94a550 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 dc0ed61d4..cbefca016 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 a94beabef..9d0fdcace 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 b58375837..65cc18ae3 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 (till the next release + 6months) diff --git a/docs/source/devenv-install.md b/docs/source/devenv-install.md index 72f25909a..84a5babeb 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 06bdfae35..2cc72f391 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 5e97c78ec..a31208f32 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 322fe7754..967c2ad14 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 d4feec998..52310e1b8 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 2352bf09b..ab38d207d 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