Merge pull request #10 from f5devcentral/development

Merge Development -> Main for v0.6.1

.gitattributes

@@ -0,0 +1 @@
+* text=auto

.github/CODEOWNERS

@@ -0,0 +1,15 @@
+# Lines starting with '#' are comments.
+# Each line is a file pattern followed by one or more owners.
+
+# More details are here: https://help.github.com/articles/about-codeowners/
+
+# The '*' pattern is global owners.
+
+# Order is important. The last matching pattern has the most precedence.
+# The folders are ordered as follows:
+
+# In each subsection folders are ordered first by depth, then alphabetically.
+# This should make it easy to add new rules without breaking existing ones.
+
+# Global rule:
+*           @f5devcentral/application-study-tool-owners

.github/workflows/check-branch.yml

@@ -0,0 +1,18 @@
+name: Main Branch Protection
+
+on:
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  check-branch:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check branch
+        run: |
+          if [[ ${GITHUB_HEAD_REF} != development ]] && ! [[ ${GITHUB_HEAD_REF} =~ ^hotfix/ ]]; 
+          then
+            echo "Error: Pull request must come from 'development' or 'hotfix/' branch"
+            exit 1
+          fi

.github/workflows/deploy-pages.yml

@@ -11,6 +11,8 @@ jobs:
       name: github-pages
       url: ${{steps.deployment.outputs.page_url}}
     runs-on: ubuntu-latest
+    permissions:
+      id-token: write
     steps:
       - name: Checkout
         uses: actions/checkout@v4

.gitignore

@@ -0,0 +1,177 @@
+*.tar.gz
+.DS_Store
+.idea
+*.log
+
+node_modules/
+*.py[cod]
+*.egg
+build
+htmlcov
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#pdm.lock
+#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
+#   in version control.
+#   https://pdm.fming.dev/#use-with-ide
+.pdm.toml
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.env.device-secrets
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+
+#husky
+.husky/
+
+#prettier 
+ght/.prettierrc.json
+temp.json
+slc/dump.rdb
+
+playwright-report/
+test-results/

CONTRIBUTING.md

@@ -0,0 +1,100 @@
+# Contributing Guide
+
+Thank you for your interest in contributing to the Application Study Tool!
+Please read this guide for general guidelines to follow, which borrows heavily
+from those used by the Opentelemetry Collector.
+
+## How to contribute
+
+### Before you start
+
+Comment on the issue that you want to work on so we can assign it to you and
+clarify anything related to it.
+
+If you would like to work on something that is not listed as an issue,
+please create an issue and describe your proposal. It is best to do this
+in advance so that maintainers can decide if the proposal is a good fit for
+this repository. This will help avoid situations when you spend significant time
+on something that maintainers may decide this repo is not the right place for.
+
+Follow the instructions below to create your PR.
+
+### Fork
+
+In the interest of keeping this repository clean and manageable, you should
+work from a fork. To create a fork, click the 'Fork' button at the top of the
+repository, then clone the fork locally using `git clone
+git@github.com:USERNAME/application-study-tool.git`.
+
+You should also add this repository as an "upstream" repo to your local copy,
+in order to keep it up to date. You can add this as a remote like so:
+
+`git remote add upstream https://github.com/f5devcentral/application-study-tool.git`
+
+Verify that the upstream exists:
+
+`git remote -v`
+
+To update your fork, fetch the upstream repo's branches and commits, then merge
+your `development` with upstream's `development`:
+
+```
+git fetch upstream
+git checkout development
+git merge upstream/development
+```
+
+Remember to always work in a branch of your local copy, as you might otherwise
+have to contend with conflicts in `development`.
+
+
+## Required Tools
+
+Working with the project sources requires the following tools:
+
+1. [git](https://git-scm.com/)
+4. [docker](https://www.docker.com/)
+
+## Repository Setup
+
+Fork the repo and checkout  by:
+
+```
+$ git clone git@github.com:f5devcentral/application-study-tool.git
+```
+
+Add your fork as an origin:
+
+```shell
+$ cd application-study-tool
+$ git remote add fork git@github.com:YOUR_GITHUB_USERNAME/application-study-tool.git
+```
+
+## Creating a PR
+
+Checkout a new branch, make modifications, build locally, and push the branch to your fork
+to open a new PR:
+
+```shell
+$ git checkout development
+$ git checkout -b feature
+# edit
+$ git commit
+$ git push fork feature
+```
+
+### Commit Messages
+
+Use descriptive commit messages. Here are [some recommendations](https://cbea.ms/git-commit/)
+on how to write good commit messages.
+When creating PRs GitHub will automatically copy commit messages into the PR description,
+so it is a useful habit to write good commit messages before the PR is created.
+Also, unless you actually want to tell a story with multiple commits make sure to squash
+into a single commit before creating the PR.
+
+When maintainers merge PRs with multiple commits, they will be squashed and GitHub will
+concatenate all commit messages right before you hit the "Confirm squash and merge"
+button. Maintainers must make sure to edit this concatenated message to make it right before merging.
+In some cases, if the commit messages are lacking the easiest approach to have at
+least something useful is copy/pasting the PR description into the commit message box
+before merging (but see the above paragraph about writing good commit messages in the first place).