KaifAhmad1
302d0a2d75
- setup-semantica action: pass extras/version through env vars instead
of interpolating ${{ inputs.* }} directly into the bash script, which
was a script-injection vector for any caller deriving these from
event/matrix data
- install-matrix: trigger on the Release workflow's completion
(workflow_run) instead of `release: published`, since the GitHub
release is created before the PyPI upload runs - the old trigger
could race the publish and silently verify the prior version; also
assert the installed version matches the triggering release tag
- examples/ci/github-actions.yml: pin actions/checkout and
actions/setup-python to the same verified commit SHAs used elsewhere
in this repo instead of mutable v5/v6 tags, and document how to pin
the setup-semantica@main reference for production use
- examples/ci templates + README: make the requirements.txt install
step conditional (guard with `-f requirements.txt`) and call out
pyproject.toml/Poetry/Pipenv as alternatives, since the templates
previously assumed every project has a requirements.txt; CircleCI's
cache key also no longer hashes a file that may not exist
CI templates
Copy-paste starting points for wiring semantica into your own project's CI. Each file is a
complete, working config — rename it into your project (see the comment at the top of each file
for the target path) and swap the smoke-test / test step for whatever your project does with
Semantica. Each template installs semantica unconditionally and your own project's dependencies
only if a requirements.txt is present; if your project uses pyproject.toml, Poetry, or Pipenv
instead, adjust the marked install line (each file calls it out inline).
| File | Target path in your repo |
|---|---|
github-actions.yml |
.github/workflows/semantica.yml |
gitlab-ci.yml |
.gitlab-ci.yml |
circleci-config.yml |
.circleci/config.yml |
If your own project is hosted on GitHub, you can skip the setup boilerplate entirely and use Semantica's reusable composite action instead:
- uses: semantica-agi/semantica/.github/actions/setup-semantica@main
with:
python-version: '3.11'
# extras: 'explorer,all' # optional
# version: '==0.6.7' # optional, pin an exact release
@main always tracks this repo's default branch, which is convenient but — like any mutable
ref — can change out from under you between runs. For production CI, pin it to a commit SHA
instead (find one via git rev-parse against a tagged release, or the commit history for
.github/actions/setup-semantica/) and update the pin
deliberately when you want to pick up changes, the same way this repo's own workflows are pinned
(see verify-action-pins.yml).
It installs Python, caches pip, installs semantica, and verifies the import — see
.github/actions/setup-semantica/action.yml.