Feat/sphinx builders #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
LecrisUT
force-pushed
the
feat/sphinx-builders
branch
3 times, most recently
from
15af051
to
7ecbb08
Compare
The upstream issue has been fixed and released. Time to remove the temporary `xfail` from the test.
Fields that reflect parameters of a single test invocation cannot live in the `Test` class: an instance will be shared by multiple threads when being executed on multiple guests, and therefore `return_code` & co. cannot be owned by `Test`.
Refactored the code, added a unit test, documented.
Co-authored-by: Petr Šplíchal <[email protected]>
The actual context is a combination of CLI and plan's context, and it brings additional information on the test configuration that produced a given result.
The discover part of the `upgrade` execute step is just a slightly modified version of the `discover` step which defaults to using the current repository to search for available tests, in this case for upgrade tasks. Let's allow having both real plans and upgrade paths and tasks in the same repository for easier upgrade testing development.
Move the key from the `Test` class to `Core` so that it can be used for plans and stories as well. Signed-off-by: Vector Li <[email protected]> Co-authored-by: Petr Šplíchal <[email protected]>
Some errors might have added context that would be helpful for investigation: the plugin itself is "just" an API client, and often the important info comes back in API responses.
Makes typing nicer for check plugins that provide their custom `Check` subclass.
Just --image was available, and muscle memory is hard.
The reboot count is owned by a test invocation instance. All reboot-related methods accept a single argument, the invocation instance. This makes the code prime candidate for being owned by the invocation class as well. I added a bit of refactoring and polishing: the base is a mere move from plugin-level methods into the `TestInvocation` class. On top of that, a bit of reformatting added as I was fixing `self` and `invocation` references, plus few recent goodies were used, namely the cached property. While working on a watchdog functionality, there will be an async reboot request. As of now, the idea is for the watchdog to set a flag in the test invocation instance, the flag which would be also consumed by the `reboot_requested` property. Another point towards the invocations owning reboot handling.
Add a note, in case users set inproper values for the Polarion report options. Fix the `tmt` name spelling. Co-authored-by: Petr Šplíchal <[email protected]>
To support a watchdog check (teemtee#1523), tmt must learn more about rebooting a guest, especially when the SSH connection is no longer available. The patch begins by extending the `connect` plugin to support custom commands. This will help with the testing and local runs. Imagine a Beaker box, reserved outside of tmt, used with `connect` plugin. The test may render the box unresponsive, in which case the SSH & a remote `reboot` command are not possible. For local runs and testing we can provide `connect` with info to trigger reboot even in those conditions, e.g. with `soft-reboot: bkr system-power --action reboot $IP`. This comes with a bit of refactoring, to allow `reboot` to run a command on the runner rather than on the guest.
There is a class of commands whose output is interesting only when they fail. Allow running them, and do not log their output in real-time, but log it if the command exits with non-zero exit code.
More and more we see the need for primitives like "install a package". Plugins start to require packages to be present on guests, we already do have `prepare/install` plugin, and the upcoming all mighty install plugin. To support all these functions, `tmt.package_managers` would provide necessary primitives, allowing implementations to be shipped as plugins. The patch starts building the primitives, converting `tmt.steps.prepare.install` to use them in the process.
In order to ensure that docs can be successfully built and the full test execution is not needed for documentation-only changes let's enable `/plans/install/docs` for the core packit jobs. Also, I propose to use the `fedora-latest-stable` target for the core jobs as it should cover the basic functionality just fine.
Add `modified_ref`,`HEAD` commit hash output Print that nothing is selected
Previously it selected all tests. Now it respects that if nothing is modified then nothing is selected. Fix: teemtee#2449
Introduce a new environment variable, `TMT_TEST_ITERATION_ID`, which is accessible to the test script. This variable combines a unique run ID and the test's serial number. The value of this variable should be different with each new test execution. Resolves: teemtee#2632
These examples should, of course, use `try`, not the `run` subcommand.
There's a bunch of tests which are executed under the `virtual` provision plan which can take a little bit more time. I suggest to increase the default `duration` as I'm not sure it's really worth to fine tune the value individually and `10m` sounds reasonable. I believe we don't have to be that strict.
Make it clear that plan cannot define context for itself.
Introduce a new `TMT_REPORT_ARTIFACTS_URL` environment variable for the tmt run process and put it in the launch's description field on ReportPortal. Fixes teemtee#2660.
Add ansible-lint to the pre-commit-config file, and fix failures/warnings for ansible files as well. Signed-off-by: Vector Li <[email protected]>
Raise `DiscoverError` if git root != fmf root.
- manual addition of environment variables for options (for report step via fmf) - modified launch-description option to append an existing description instead of overwriting
Add support for `apk` package manager from Alpine Linux. Unsupported debuginfo installation, seems not have a nice `debuginfo-install`-like solution. Installing by path is limited to certain recognized paths. The existing `apk-file` solution looks flaky, it was randomly hanging and does not have a good machine readable output. For testing we need to use a locally build alpine image which contains required packages of tmt and the unit tests. Resolves teemtee#2694 Signed-off-by: Miroslav Vadkerti <[email protected]>
Co-authored-by: Martin Hoyer <[email protected]>
…eemtee#2775) When Beaker API client instance is initialized, it records active Kerberos client. Which may easily expire, or get refreshed, but mrack would not know and stick to the old one. That results into Beaker cleanup failing, as reported in teemtee#2774
Add forgotten f-string to properly render the default value in the `--help` message.
Signed-off-by: Cristian Le <[email protected]>
- Call `make generate` inside conf.py - Remove sphinx builder make targets Signed-off-by: Cristian Le <[email protected]><[email protected]>
Signed-off-by: Cristian Le <[email protected]>
happz
force-pushed
the
feat/sphinx-builders
branch
from
c4ecb8b
to
b05e5b6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Checklist