stub component and ci basics

[ms-lolo]

• created stub python component using uv
• added test tooling
• added mkdocs
• added empty README.md symlinked from the docs home page
• added branch policies
• added dependabot configuration to automatically update ci pipelines and python packages
• added basic ci pipelines with linting, testing, and documentation
• building a wheel and container image as a smoke test for the python pkg

extra notes and homework

• the docs should be updated with new logo files. this is a template copied from rats and resys repos.
• the docker build should be updated with a command that smoke tests something trivial but real once there is something implemented.
• the docker image is using pip to install the package as a way to test how your package would behave outside of a development environment, if it were ever to be released. it ensures the boundaries between the development tooling and the package are clear and the package remains valid. this means the docker image intentionally does not have development tools in it, like pytest, ruff, pyright, and mkdocs.
• branch policies should be updated with your desired values.
• the unit test simply imports the module and makes sure it's valid so that the pytest and coverage tools don't fail. it should be deleted once real code is added and real tests created.
• linting and typing configuration was copied from rats project, but should be updated with your preferences.

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[Copilot]

Pull Request Overview

This PR establishes the foundational structure for the SNRAware project, including project configuration, build system, documentation framework, CI/CD workflows, and development tooling.

• Sets up Python package structure with pyproject.toml, build configuration, and development dependencies
• Configures documentation using MkDocs with Material theme and multiple plugins
• Implements GitHub Actions workflows for PR checks, builds, and releases
• Establishes code quality tooling (ruff, pyright, pytest) with comprehensive configuration

Reviewed Changes

Copilot reviewed 20 out of 25 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pyproject.toml	Configures project metadata, dependencies, build system, and tooling (pyright, ruff, pytest, coverage)
uv.lock	Locks all dependency versions for reproducible builds
mkdocs.yaml	Configures MkDocs documentation site with Material theme and various extensions
justfile	Defines common development tasks (lint, test)
src/snraware/init.py	Creates empty package module with docstring
test/snraware_test/test_basics.py	Adds basic sanity test for module import
.github/workflows/*.yaml	Sets up CI/CD pipelines for PR checks, builds, and releases
.github/policies/branch-protection.yml	Configures branch protection policy
docs/*	Adds documentation structure with index, images, and custom CSS
.gitignore	Adds Python-specific ignore rules

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Hui Xue (xueh2)]

First PR to bring in the CI pipeline.

[Joe Naegele (naegelejd)]

This is great, lots of good patterns.

All of my feedback/questions are toward the pipeline template, not this specific repository.

[Joe Naegele (naegelejd)]

Better to require one approving review and restrict pushes to main for any repo that isn't a toy project.

[ms-lolo]

updated!

[ms-lolo]

do you know why adding these policies made my ci fail? finding this error a bit vague https://github.com/microsoft/SNRAware/pull/4/checks?check_run_id=54642380794

[ms-lolo]

ok i updated the reviewer count, but i undid the change to restrict pushes because i don't think it behaves like we want. when i enable restrictsPushes, it requires me to name people that can push to the branch. but we don't want anyone to ever push to main, so i think what you want is the standard branch protection rules you can specify on the github repo settings. let me know if you've done this before and want something else!

[Joe Naegele (naegelejd)]

Just checking: What happens if the PR workflow (in pr.yaml) fails in parallel with this workflow? Is it possible for this PR to be "automerged" before the other workflow finishes?

[ms-lolo]

no, this is basically making it so that dependabot PRs will automatically merge as long as every CI check has passed.

[ms-lolo]

it's confusing to me too, but this template has been used in other repos and it's definitely how it behaves :) i think the --auto is key here, and i think it's basically enabling the auto merge flag which you can use on any pr in order to tell github to merge as soon as all the conditions have been met (people resolve comments, pr approvals, ci checks, etc.).

[Joe Naegele (naegelejd)]

This workflow is nearly identical to the main.yaml workflow. Can we deduplicate them and parameterize the two things that differ (contents permission and publish-docs variable)?

[Joe Naegele (naegelejd)]

We also probably want to be able to trigger this workflow on workflow_dispatch, i.e. run it manually, especially if something goes wrong during the workflow triggered on merge to main (I've seen this happen many times)

[ms-lolo]

i merged the two into main.yaml and used ${{ github.ref_name == 'main' }} to decide when to deploy docs. i'll keep an eye out when we merge to main to make sure it behaves as expected.

curious when you would run the workflow manually vs re-running a failed build. could you help me understand the scenario? i think i had things written using workflow_dispatch in the past but it looks like it got removed and i can't find the reason in the git histories.

[ms-lolo]

went ahead and implemented this but the web ui doesn't seem to be letting me trigger the workflow yet. i think it's because it's not in main yet. i'll test further once this pr merges but i've exposed the same sha input so we can run the workflow specified in any branch, and apply it to any commit hash. i went ahead and added the same dispatch block to all workflows except the release.yaml file, because releases depend on other workflows and cannot be run individually.

[Joe Naegele (naegelejd)]

This input isn't used, I assume because a checkout isn't needed... or the deploy-pages action just uses ${{ github.sha }}.

[ms-lolo]

took it out. might have been needed with more complex release steps like deploying apps and publishing containers/packages in other repos

[Joe Naegele (naegelejd)]

Just checking: Why do we need to "pass in" github.sha to every workflow call?

[ms-lolo]

i'm failing to remember. my guess is it was needed when i had every workflow as being able to be called with workflow_dispatch. do you mind if i experiment with removing it in a follow up pr so i can unblock Hui for now? if it's not needed i'd like to remove it from all the repo pipelines.

also curious if you would prefer i make all of these include workflow_dispatch instead of removing this variable, so we can manually run these smaller workflows on any commit easily. i can go in either direction in a follow up pr. i don't have a strong preference but am leaning towards leaving the variable and adding workflow_dispatch to make development easier.