Bootstrap CI/CD – Questions

Goal: define initial CI/CD checks and local Docker-parity hooks for this repo (docs/site, scripts, docker-compose), and a template usable by other repos.

Answer style: short codes + notes, e.g. `1:a,c 2:b 3:docker`.

1) Stacks present now (select all):
   - a) Shell scripts
   - b) Dockerfiles/Compose
   - c) Markdown/Docs
   - d) YAML (workflows/config)
   - e) Python
   - f) Node/JS
   - g) Other (specify)

   a,b,c,d potentially e. 

2) Formatters/linters per stack:
   - shell: a) shfmt b) shellcheck c) both
   - docker: a) hadolint
   - markdown: a) markdownlint b) prettier c) both
   - yaml: a) yamllint b) actionlint (for workflows) c) both
   - python (if used): a) black b) ruff c) pytest (tests)
   - node (if used): a) eslint b) prettier c) jest (tests)
   
   shell: c
   docker: a
   markdown: c
   yaml: c

   I will leave python/node testing up to you. It isn't needed for this repo unless you create python scripts at some point.

3) Testing scope now:
   - a) none (docs/scripts only)
   - b) smoke tests for scripts (bats/pytest-sh)
   - c) unit tests for scripts (specify framework)

   A (other then linting)

4) Security scanning:
   - a) trivy fs
   - b) grype
   - c) bandit (python)
   - d) npm audit (node)
   - e) skip for this repo

   e

5) Execution environment for CI:
   - a) run inside repo’s `ci.Dockerfile`
   - b) run on runner host with packages
   - c) mix (specify)

   All execution MUST be done in docker containers. Absolutely no work must be done on the host beyond git operations and docker orchestration.

6) Matrix needs (now):
   - a) none (single Linux image)
   - b) multiple language versions (specify)
   - c) OS matrix (Linux only for now?)

   Um. I don't know. I think just a simle Linux environment can be assumed? 

7) Caching:
   - a) enable tool caches (pip/npm) in CI
   - b) enable Docker layer cache
   - c) none

   I guess docker layer cache? It will be two weeks before I'm working on software (and therefore setup gitea CI runners etc). 

8) Check names to protect on branches (final labels):
   - a) ci / lint
   - b) ci / test
   - c) ci / build
   - d) ci / security
   - e) ci / commitlint

   I don't know, leave it up to you

9) Hooks parity:
   - pre-commit: run format+lint+commitlint? (y/n) y
   - pre-push: run test+build+security (fast profile)? (y/n) y

10) Concurrency & timeouts:
   - cancel in-progress on new commits to same PR? (y/n)
   - default job timeout (minutes)?

11) Release flow details:
   - generate release notes from merged PRs since last tag? (y/n)
   - attach built artifacts (site tarball, etc)? (y/n)

12) Coverage gates (if tests exist):
   - threshold % to require? (number or skip)

13) Auto-merge bot to `integration`:
   - bot account/name (or use Gitea built-in)?
   - automerge conditions beyond green checks? (labels, size)

14) Notifications:
   - a) none
   - b) email
   - c) webhook/Chat (specify)

15) Future extensibility:
   - template these workflows for other repos? (y/n)
   - segregate language-specific jobs behind conditions? (y/n)

Notes: add any constraints about runners, container registry, or build tools.


Lets just ignore all things CI for now? I'm brand new to CI. Use your best judgement/adopt best practices and/or ignore CI as needed. Do track that it's an outstanding item to go in depth on though. I don't want it to block moving forward with the dozen or so docs repos I need to use this LLM workflow with though.