Move flaky remote tests into "scheduled" workflow.

1 files changed, 19 insertions, 10 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d0b52a4d..6c339a99 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,12 +1,12 @@
 # Contributing
 
-You contribution is warmly welcomed. You can help by:
+Your contribution is warmly welcomed. You can help by:
 
- 0. Spread the word about this project, look at generated processed webpages
- 1. Trying the tool and reporting issues and suggestions for improvement (open Github issue)
- 2. Add new regular expressions to extract relevant information from certificates (update cert_rules.py)
- 3. Perform additional analysis with extracted data (analyze_certificates.py)
- 3. Improve the code (TODO: Follow Github contribution guidelines, ideally contact us first about your plan)
+ 1. Spreading the word about this project, using our website [sec-certs.org](https://sec-certs.org)
+ 2. Trying the tool and reporting issues and suggestions for improvement (open a GitHub issue)
+ 3. Adding new regular expressions to extract relevant information from certificates (update `rules.yaml`)
+ 4. Performing additional analysis with extracted data (let us know about your findings)
+ 5. Improving the code (Follow Github contribution guidelines, ideally contact us first about your plan)
 
 ## Dependencies
 
@@ -30,7 +30,7 @@ Requirements are maintained with [pip-tools](https://github.com/jazzband/pip-too
 - `setuptools-scm` will automatically, upon editable/real install of a package, infer its version and write it to `sec_certs/_version.py`. This file is not indexed as well. See more at [setuptools-scm GitHub](https://github.com/pypa/setuptools_scm)
 - On publishing a release, the tool is automatically published to [PyPi](https://pypi.org/project/sec-certs/) and [DockerHub](https://hub.docker.com/repository/docker/seccerts/sec-certs).
 
-Note on single-sourcing the package version: More can be read [here](https://packaging.python.org/en/latest/guides/single-sourcing-package-version/). The downside of our approach is that `.git` folder and editable/real install is needed to infer the version of the package. Releases can be infered without installing the project.
+Note on single-sourcing the package version: More can be read [here](https://packaging.python.org/en/latest/guides/single-sourcing-package-version/). The downside of our approach is that `.git` folder and editable/real installation is needed to infer the version of the package. Releases can be inferred without installing the project.
 
 ### Currently, the release process is as follows
 
@@ -46,7 +46,7 @@ All commits shall pass the lint pipeline of the following tools:
 - Mypy (see [pyproject.toml](https://github.com/crocs-muni/sec-certs/blob/main/pyproject.toml) for settings)
 - Ruff (see [pyproject.toml](https://github.com/crocs-muni/sec-certs/blob/main/pyproject.toml) for settings)
 
-These tools can be installed via [dev_requirements.txt](https://github.com/crocs-muni/sec-certs/blob/main/requirements/dev_requirements.txt) You can use [pre-commit](https://pre-commit.com/) tool to register git hook that will evalute these checks prior to any commit and abort the commit for you. Note that the pre-commit is not meant to automatically fix the issues, just warn you.
+These tools can be installed via [dev_requirements.txt](https://github.com/crocs-muni/sec-certs/blob/main/requirements/dev_requirements.txt) You can use [pre-commit](https://pre-commit.com/) tool to register git hook that will evaluate these checks prior to any commit and abort the commit for you. Note that the pre-commit is not meant to automatically fix the issues, just warn you.
 
 It should thus suffice to:
 
@@ -56,14 +56,23 @@ pre-commit install &&
 pre-commit run --all-files
 ```
 
-To ivoke the tools manually, you can, in the repository root, use:
+To invoke the tools manually, you can, in the repository root, use:
 - Mypy: `mypy .`
 - Ruff: `ruff ." (or with `--fix` flag to apply fixes)
 - Ruff formatL `ruff format --check .`
 
+## Tests
+
+Tests are run with `pytest`. The tests are located in `tests` folder and are run with `pytest tests`. The tests are also run on every push to the repository with Github Actions.
+There are two custom markers for the tests:
+- `slow` for tests that take longer time to run
+- `remote` for tests that require remote resources and are thus flaky.
+
+To exclude slow tests, use `pytest -m "not slow"`. To exclude remote tests, use `pytest -m "not remote"`. To run only slow tests, use `pytest -m "slow"`. To run only remote tests, use `pytest -m "remote"`.
+
 ## Documentation
 
-Every public method of a module that can be leveraged as an API by user should be documented. The docstrng style should
+Every public method of a module that can be leveraged as an API by user should be documented. The docstring style should
 be `sphinx-oneline`.
 
 The documentation is built using `sphinx` with `mnyst` extension that allows for markdown files. Folder `notebooks/examples` is symbolically linked to `/docs` and its contents will be automatically parsed. These notebooks are supposed to be runnable from Binder.