Skip to content

Commit 9725cf8

Browse files
sanjeevredsanjeevred
committed
SRS initial commit
0 parents  commit 9725cf8

File tree

426 files changed

+29839
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

426 files changed

+29839
-0
lines changed

‎.env.template‎

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# this file is a template for creating your own .env file
2+
# the variables below will be passed to all containers run locally, and
3+
# should be defined before running full integration tests
4+
# see https://pypi.org/project/python-dotenv/ for full format specification
5+
6+
# workspaces token used by the slackwatchman service
7+
SLACK_TOKEN=
8+
9+
# important env variable for certain orchestrator endpoints
10+
# do not change this for local testing
11+
ORCHESTRATOR_SERVICE_NAME=prodsec_automation_toolkit_play
12+
13+
# values used by the sqlcache age-off script
14+
# time in seconds between age-off operations
15+
AGEOFF_INTERVAL=86400
16+
# remove anything older than the below number of hours
17+
AGEOFF_AGE_IN_HOURS=24
18+
19+
# HOST RESOLUTION CONFIGURATION
20+
# -----------------------------------------------------------------------------
21+
# This section is used to define the hosts and ports on which services within
22+
# the SRS ecosystem are accessible for local testing. Configurations should
23+
# follow the format:
24+
#
25+
# <SERVICE_NAME>_SERVICE_HOST=host.docker.internal
26+
# <SERVICE_NAME>_SERVICE_PORT=<SERVICE_PORT>
27+

‎.gitattributes‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
components/blueprints/api/v1/clamav/main.cvd filter=lfs diff=lfs merge=lfs -text

‎.github/actions/use-venv/action.yml‎

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
inputs:
2+
python-version:
3+
default: '3.9'
4+
venv-artifact-name:
5+
default: 'venv-tar'
6+
runs:
7+
using: composite
8+
steps:
9+
- name: Set up Python
10+
uses: actions/setup-python@v4
11+
with:
12+
python-version: ${{ inputs.python-version }}
13+
14+
- name: Download venv artifact
15+
uses: actions/download-artifact@v4
16+
with:
17+
name: ${{ inputs.venv-artifact-name }}
18+
path: .
19+
20+
- name: Extract venv
21+
shell: bash
22+
run: |
23+
tar -xzf venv.tar.gz
24+
# Re-create top-level venv directory layout (optional consistency)
25+
mkdir -p venv
26+
mv venv/pat_dev_vm 2>/dev/null || true # noop if already correct
27+
if [ ! -d venv/pat_dev_vm ]; then
28+
# If tar expanded directly:
29+
mv pat_dev_vm venv/ || true
30+
fi
31+
ls -l venv/pat_dev_vm/bin

‎.github/workflows/ci.yml‎

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
name: CI/CD Pipeline
2+
3+
on:
4+
push:
5+
branches: [ '**' ]
6+
pull_request:
7+
branches: [ main, develop ]
8+
9+
env:
10+
PYTHON_VERSION: '3.9'
11+
12+
jobs:
13+
setup:
14+
name: Setup Virtual Environment
15+
runs-on: ubuntu-latest
16+
steps:
17+
- name: Checkout code
18+
uses: actions/checkout@v4
19+
with:
20+
submodules: recursive
21+
fetch-depth: 1
22+
23+
- name: Set up Python
24+
uses: actions/setup-python@v4
25+
with:
26+
python-version: ${{ env.PYTHON_VERSION }}
27+
28+
- name: Create virtual environment
29+
run: |
30+
echo "Standing up venv for tests..."
31+
make venv
32+
33+
- name: Archive venv (preserve structure)
34+
run: |
35+
tar -czf venv.tar.gz venv/pat_dev_vm
36+
ls -lh venv.tar.gz
37+
38+
- name: Upload venv artifact
39+
uses: actions/upload-artifact@v4
40+
with:
41+
name: venv-tar
42+
path: venv.tar.gz
43+
retention-days: 1
44+
45+
version-canary:
46+
name: Version Canary Check
47+
runs-on: ubuntu-latest
48+
needs: setup
49+
if: github.ref != 'refs/heads/develop' && github.ref != 'refs/heads/main'
50+
steps:
51+
- name: Checkout (needed before using local action)
52+
uses: actions/checkout@v4
53+
with:
54+
submodules: recursive
55+
fetch-depth: 1
56+
57+
- name: Prepare env
58+
uses: ./.github/actions/use-venv
59+
with:
60+
python-version: ${{ env.PYTHON_VERSION }}
61+
venv-artifact-name: 'venv-tar'
62+
63+
- name: Run version canary
64+
run: |
65+
echo "Running version canary..."
66+
make version_canary
67+
68+
unit-tests:
69+
name: Unit Tests
70+
runs-on: ubuntu-latest
71+
needs: setup
72+
if: github.ref != 'refs/heads/develop' && github.ref != 'refs/heads/main'
73+
steps:
74+
- name: Checkout (needed before using local action)
75+
uses: actions/checkout@v4
76+
with:
77+
submodules: recursive
78+
fetch-depth: 1
79+
80+
- name: Prepare env
81+
uses: ./.github/actions/use-venv
82+
with:
83+
python-version: ${{ env.PYTHON_VERSION }}
84+
venv-artifact-name: 'venv-tar'
85+
86+
- name: Run unit tests
87+
run: |
88+
echo "Running unit tests..."
89+
make test
90+
91+
# Summary job that depends on all other jobs
92+
ci-complete:
93+
name: CI Pipeline Complete
94+
runs-on: ubuntu-latest
95+
needs: [setup, version-canary, unit-tests]
96+
if: always()
97+
steps:
98+
- name: Check all jobs status
99+
run: |
100+
echo "Setup: ${{ needs.setup.result }}"
101+
echo "Version Canary: ${{ needs.version-canary.result }}"
102+
echo "Unit Tests: ${{ needs.unit-tests.result }}"
103+
104+
if [[ "${{ contains(needs.*.result, 'failure') }}" == "true" ]]; then
105+
echo "One or more jobs failed"
106+
exit 1
107+
else
108+
echo "All applicable jobs completed successfully"
109+
fi

‎.gitignore‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
*.swp
2+
.DS_Store
3+
.idea/
4+
*.pyc
5+
venv/
6+
__pycache__/
7+
.env
8+
*.db

‎CONTRIBUTING.md‎

Lines changed: 122 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
# Contributing to Scan Request Service (SRS)
2+
3+
Welcome! We’re excited you want to help make SRS better. This short guide walks you through:
4+
5+
1. [Setting up a development environment](#1-development-environment-setup)
6+
2. [Understanding the project structure](#2-project-structure-high-level)
7+
3. [What to do before you open a Pull Request](#3-pull-requests-guidelines--presubmission-steps)
8+
4. [How to report issues](#4-reporting-issues)
9+
5. [Our code of conduct](#5-code-of-conduct)
10+
11+
If you need further explanations or guidance, browse our [documentation](./docs/) and [Developer FAQ](./docs/developer_faq.md).
12+
13+
---
14+
## 1. Development Environment Setup
15+
### Prerequisites:
16+
* Python ≥ 3.10
17+
* pip
18+
* virtualenv
19+
* Docker
20+
* GNU make
21+
* libmagic (for python-magic)
22+
23+
### Steps:
24+
```bash
25+
make venv # creates venv/pat_dev_vm (dev virtualenv)
26+
make help # verify automation & targets render
27+
make test # run unit tests
28+
```
29+
You normally do NOT need to manually `source` the venv; the `make` automation handles that. If a target complains that a virtualenv is active, deactivate it and retry.
30+
31+
### Other targets you may use during development:
32+
```bash
33+
make it # integration tests (pytest + tavern)
34+
make lt # load tests (k6)
35+
make bp # instantiate an empty blueprint template
36+
make service # create a service stub within the service manifest
37+
make service_up # build & run a service container
38+
```
39+
40+
---
41+
## 2. Project Structure (High Level)
42+
```
43+
components/blueprints/ # Individual business logic units (Flask blueprints)
44+
chassis/ # Shared service chassis (e.g. k_api)
45+
services/ # Service definitions (composition lives in manifests)
46+
make_lib/ # Automation scripts + blueprint & service manifests
47+
docs/ # Developer guides & reference
48+
requirements.txt # Automation / tooling deps (not baked into service images)
49+
```
50+
### Key ideas:
51+
- A service = one chassis + N blueprints.
52+
- Manifests in `make_lib/` define what blueprints and services exists, as well as how those services are composed; avoid manual edits unless extending following documented patterns.
53+
- Per‑blueprint and chassis `requirements.txt` files control runtime deps; root `requirements.txt` is only for development automation.
54+
- Use the automation whenever possible! Attempting to manually perform tasks that the automation can already handle via a `make` target can introduce unwanted behaviors.
55+
56+
---
57+
## 3. Pull Requests: Guidelines & Pre‑Submission Steps
58+
We follow a [Gitflow branching model](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow); all feature and bug branches should branch off of `develop`, while `develop` should be the only branch merging into `main`.
59+
60+
When naming branches, use concise and unambiguous terminology that represents the work contained on the branch. Feature and bug branches should be prefixed with `feature/` and `bugfix/` respectively.
61+
62+
### Before you open a PR:
63+
1. Keep scope focused (one logical change).
64+
2. Run and pass:
65+
66+
```bash
67+
make test
68+
make version_canary # ensures version & changelog alignment
69+
```
70+
Run `make it` / `make lt` if you changed integration or performance-sensitive code.
71+
3. Bump versions (chassis / blueprint / template / service) and update their README changelogs if any related code was changed.
72+
4. Update OpenAPI docs if you changed an API contract.
73+
5. Ensure any code changes are covered by unit tests.
74+
6. Ensure no stray debug prints, commented-out code, or secrets exist in the PR.
75+
7. Rebase your branch on the latest `develop` and squash to a single meaningful commit.
76+
8. Write a clear commit message: `feat(ping): add latency metric` (prefixes: feat, fix, docs, refactor, test, perf, chore, sec).
77+
9. If security-sensitive, note review considerations in the PR description.
78+
79+
### Suggested PR checklist (copy into description):
80+
```
81+
[ ] Single logical change (squashed & rebased on develop)
82+
[ ] Versions bumped + changelogs updated
83+
[ ] Tests added/updated & passing (unit + integration if needed)
84+
[ ] make version_canary passes
85+
[ ] OpenAPI spec updated (if API change)
86+
[ ] No secrets / debug leftovers
87+
[ ] Docs/help updated if user-facing behavior changed
88+
```
89+
At least one reviewer approval is required. Provide context for your proposed changes (why, not just what) so reviewers can move quickly.
90+
91+
---
92+
## 4. Reporting Issues
93+
Please search existing issues and the [FAQ](./docs/developer_faq.md) first.
94+
95+
Include in a new issue:
96+
- Environment (OS, Python version, Docker version)
97+
- Exact commands or steps to reproduce
98+
- Expected vs actual result
99+
- Relevant logs / stack traces / screenshots
100+
101+
For suspected security vulnerabilities or anything that could expose sensitive data, **do not** open a public issue—use Splunk’s responsible disclosure process instead.
102+
103+
### Feature requests:
104+
Describe the use case and why existing functionality is insufficient. Implementation suggestions are welcome, but keep them concise.
105+
106+
---
107+
## 5. Code of Conduct
108+
We are committed to a respectful, inclusive, and harassment‑free collaborative environment. By participating you agree to:
109+
- Assume good intent; ask clarifying questions before criticizing
110+
- Offer constructive, actionable feedback
111+
- Avoid discriminatory or exclusionary language
112+
- Respect differing experience levels and backgrounds
113+
114+
Unacceptable behavior (harassment, personal attacks, derogatory comments, sharing private information) may result in removal from discussions or other corrective action. Escalate concerns privately to the maintainers.
115+
116+
---
117+
## Need Help?
118+
1. Read the [docs](./docs/) & [FAQ](./docs/developer_faq.md).
119+
2. Open a detailed [issue](https://github.com/splunk/scan-request-service/issues/new).
120+
3. For security, use private disclosure channels.
121+
122+
We appreciate every improvement — large or small. Thank you for bettering SRS for the community :heart:

0 commit comments

Comments
 (0)