link updates and workflows

Author: JoschD

.github/CODEOWNERS

@@ -0,0 +1,7 @@
+# https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
+
+# GLOBAL CODEOWNERS ---
+# These owners will be the default owners for everything in
+# the repo. Unless a later match takes precedence,
+# they will be requested for review when someone opens a pull request.
+*       @pylhc/approved-reviewers

.github/workflows/README.md

@@ -0,0 +1,28 @@
+# Continous Integration Workflows
+
+This package implements different workflows for CI, based on our organisation's common workflows.
+They are organised as follows.
+
+### Documentation
+
+The `documentation` workflow triggers on any push to master, builds the documentation and pushes it to the `gh-pages` branch (if the build is successful).
+
+### Testing Suite
+
+Tests are ensured in the `tests` workflow, which triggers on all pushes.
+It runs on a matrix of all supported operating systems for all supported Python versions.
+
+### Test Coverage
+
+Test coverage is calculated in the `coverage` wokflow, which triggers on pushes to `master` and any push to a `pull request`.
+It reports the coverage results of the test suite to `CodeClimate`.
+
+### Regular Testing
+
+A `cron` workflow triggers every Monday at 3am (UTC time) and runs the full testing suite, on all available operating systems and supported Python versions.
+It also runs on `Python 3.x` so that newly released Python versions that would break tests are automatically included.
+
+### Publishing
+
+Publishing to `PyPI` is done through the `publish` workflow, which triggers anytime a `release` is made of the GitHub repository.
+It builds a `wheel`, checks it, and pushes to `PyPI` if checks are successful.

.github/workflows/coverage.yml

@@ -0,0 +1,15 @@
+# Runs all tests and pushes coverage report to codeclimate
+name: Coverage
+
+on:  # Runs on all push events to master branch and any push related to a pull request
+  push:
+    branches:
+      - master
+  pull_request:  # so that codeclimate gets coverage and reports on the diff
+
+jobs:
+  coverage:
+      uses: pylhc/.github/.github/workflows/coverage.yml@master
+      with:
+        src-dir: pylhc_submitter
+      secrets: inherit

.github/workflows/cron.yml

@@ -0,0 +1,11 @@
+# Runs all tests on master on Mondays at 3 am (UTC time)
+name: Cron Testing
+
+
+on:
+  schedule:
+    - cron:  '* 3 * * mon'
+
+jobs:
+    tests:
+      uses: pylhc/.github/.github/workflows/cron.yml@master

.github/workflows/documentation.yml

@@ -0,0 +1,14 @@
+# Build documentation
+# The build is uploaded as artifact if the triggering event is a push for a pull request
+# The build is published to github pages if the triggering event is a push to the master branch (PR merge)
+name: Build and upload documentation
+
+on:  # Runs on any push event in a PR or any push event to master
+  pull_request:
+  push:
+    branches:
+      - 'master'
+
+jobs:
+  documentation:
+        uses: pylhc/.github/.github/workflows/documentation.yml@master

.github/workflows/publish.yml

@@ -0,0 +1,11 @@
+# Publishes to PyPI upon creation of a release
+name: Upload Package to PyPI
+
+on:  # Runs everytime a release is added to the repository
+  release:
+    types: [created]
+
+jobs:
+  deploy:
+    uses: pylhc/.github/.github/workflows/publish.yml@master
+    secrets: inherit

.github/workflows/tests.yml

@@ -0,0 +1,23 @@
+# Runs all tests
+name: All Tests
+
+defaults:
+  run:
+    shell: bash
+
+on:  # Runs on any push event to any branch except master (the coverage workflow takes care of that)
+  push:
+    branches-ignore:
+      - 'master'
+
+jobs:
+  tests:
+    uses: pylhc/.github/.github/workflows/tests.yml@master
+    with:
+      pytest-options: -m "not example"
+
+  examples:
+    needs: tests
+    uses: pylhc/.github/.github/workflows/tests.yml@master
+    with:
+      pytest-options: -m "example"

README.md

@@ -82,15 +82,15 @@ A lot of details about the individual steps can be found in the examples.
 ### 2022 Commissioning Example
 
 An example for the 2022 commissioning measurements can be found in
-[`examples/2022_commissioning.py`](https://github.com/pylhc/ir_amplitude_detuning/blob/master/examples/commissioning_2022.py).
+[`examples/commissioning_2022.py`](https://github.com/pylhc/ir_amplitude_detuning/blob/master/examples/commissioning_2022.py).
 This example is the most basic one and implements only a single `Target`:
 
 - Target 1: Correcting the detuning change between full crossing scheme enabled and flat orbit (a single `TargetData`).
 
 ### 2018 MD3311 Example
 
 A slightly more complex example for the 2018 MD3311 measurements can be found in
-[`examples/2018_md3311.py`](https://github.com/pylhc/ir_amplitude_detuning/blob/master/examples/md3311_2018.py).
+[`examples/md3311.py`](https://github.com/pylhc/ir_amplitude_detuning/blob/master/examples/md3311.py).
 Here, three different TArgets are defined:
 
 - Target 1: Correcting the detuning change between full crossing scheme enabled and flat orbit.
@@ -99,7 +99,7 @@ Here, three different TArgets are defined:
 
 ### 2022 MD6863 Example
 
-In the example [`examples/2022_md6863.py`](https://github.com/pylhc/ir_amplitude_detuning/blob/master/examples/md6863_2022.py),
+In the example [`examples/md6863.py`](https://github.com/pylhc/ir_amplitude_detuning/blob/master/examples/md6863.py),
 the measurements from MD6863 in 2022 are directly loaded from the analysed detuning output files from `omc3`,
 which makes already the first step more complex in code and requires a well defined naming scheme for the files.