Security issues in workflows

.github/workflows/ci.yml

@@ -41,9 +41,12 @@ jobs:
         uses: astral-sh/setup-uv@v6
         with:
           enable-cache: true
+
+      - name: Install dependencies
+        run: uv sync --group dev # NOSONAR
 
       - name: Run tests
-        run: uv run pytest --cov . --cov-report xml:.coverage-reports/coverage.xml
+        run: .venv/bin/pytest --cov . --cov-report xml:.coverage-reports/coverage.xml
 
       - name: SonarCloud Scan
         uses: SonarSource/sonarqube-scan-action@v5.3.0

.github/workflows/release.yml

@@ -93,10 +93,10 @@ jobs:
           uv lock --check
 
       - name: Install Dependencies
-        run: uv sync --frozen --group dev --group docs
+        run: uv sync --frozen --group dev --group docs # NOSONAR
 
       - name: Generate changelog
-        run: uv run cz changelog --unreleased-version="${{ steps.get_version.outputs.VERSION }}" --incremental
+        run: .venv/bin/cz changelog --unreleased-version="${{ steps.get_version.outputs.VERSION }}" --incremental
 
       - name: Get user info
         id: user_info
@@ -116,7 +116,7 @@ jobs:
         run: |
           set -e  # Exit immediately if a command exits with a non-zero status
           echo "Bumping version to ${{ steps.get_version.outputs.VERSION }}"
-          uv run cz bump --yes --check-consistency "${{ steps.get_version.outputs.VERSION }}"
+          .venv/bin/cz bump --yes --check-consistency "${{ steps.get_version.outputs.VERSION }}"
 
           echo "Updating lock file after version bump"
           uv lock
@@ -141,7 +141,7 @@ jobs:
 
       - name: Build wheel with uv
         run: |
-          uv build
+          uv build # NOSONAR
           echo "WHEEL_PATH=$(ls -t dist/*.whl | head -n 1)" >> $GITHUB_ENV
 
       - name: Create GitHub release

docs/dev_docs/contributing.md

@@ -35,7 +35,7 @@ With a supported environment manager installed, set up your development environm
 
 ## Style & documentation conventions
 
-We use [ruff](https://github.com/astral-sh/ruff) for linting and code formatting. 
+The projects uses [ruff](https://github.com/astral-sh/ruff) for linting and code formatting. 
 Documentation is based on [mkdocs](https://www.mkdocs.org/) and [mkdocstringds](https://mkdocstrings.github.io/#:~:text=mkdocstrings.%20Automatic%20documentation%20from%20sources,%20for). Numpy, sphinx and google-style
 docstrings are supported, but when writing new code please use [Google-style docstring syntax](https://mkdocstrings.github.io/griffe/docstrings/#google-style)
 
@@ -62,22 +62,23 @@ unless all tests are passing. To run tests locally, use `pytest`:
 
 ## Deploying
 
-### Locally build executable (optional)
-
-To build a local version of an FM2PROF executable, run:
-
-`uv run pyinstaller FM2PROF_WINDOWS.spec`
+### How to make a new release
 
-!!! note
+Releases follow a manual procedure detailed below. 
 
-    Executables are no longer automatically made since fm2prof was published on pypi 
+#### Update the version number
 
+The version number is updated in `pyproject.toml`
 
-### How to make a new release
+``` toml
+[project]
+name = "fm2prof"
+version = "2.5.1"
+```
 
-Publishing a new release takes some steps. 
+The project uses regular [Semantic versioning](https://semver.org/) in `pyproject` and the online documentation, but uses the `v` prefix for github tags and releases. 
 
-#### Tag your version
+#### Create a new tag
 After merging a PR to `master`, first make a new tag. Using version `v2.3.0` as an example, 
 a tag can be made via the terminal:
 
@@ -86,8 +87,10 @@ git tag v2.3.0
 ```
 #### Make a new release
 
-Use Github interface to draft a new release using the appropriate. Document all changes since the previous version. 
-If possible, refer to Github Issues. 
+Use Github interface to draft a new release. Document all changes since the previous version. 
+When possible, refer to Github Issues. 
+
+A pdf version of the documentation should be automatically uploaded to the release from the `generate_latex.yml` workflow. 
 
 #### Update the documentation
 We use [mike](https://github.com/jimporter/mike) as a pre-processor for `mkdocs`. To update the documentation