Repository Layout
Careers Engine follows a modular Python project structure. Source integrations, parsers, filtering, employment classification, storage, and publishing are organized into separate components, while tests, documentation, and automation workflows remain independently maintainable. The project also separates application code from persistent operational data through thecareers-data repository.
Repository Structure
Explore the repository interactively. Expand any folder to inspect its files and subdirectories.careers-engine
.github
workflows
ci.yml
ingest.yml
publish.yml
queue_opportunity.yml
docs
scripts
src
careers_engine
company
discord
telegram
fetchers
filters
models
parsers
sources
storage
config.py
employment.py
pipeline.py
__init__.py
tests
.env.example
.gitignore
.pre-commit-config.yaml
CONTRIBUTING.md
LICENSE
Makefile
pyproject.toml
uv.lock
The tree focuses on the main source, documentation, and workflow files. Generated Python cache files and other transient files are intentionally omitted.
Application Code — src/careers_engine/
Find the source here: https://github.com/ZenYukti/careers-engine/blob/main/src/careers_engine
The application package contains the implementation of the aggregation and publishing engine.
Each component has a defined responsibility, allowing individual parts to evolve without requiring the entire pipeline to be rewritten.
For the complete data flow, see the Ingestion Pipeline.
Scripts — scripts/
The scripts directory contains the application’s executable entry points for operational workflows.
The main entry points are:
collect.py: runs the collection and ingestion process.publish.py: runs the publishing process.
Tests — tests/
The test suite validates the behavior of the application’s components.
Tests cover areas such as source adapters, parsers, eligibility filtering, employment classification, and other core logic.
The separation of components makes it possible to test parsing, classification, and destination publishing independently of scheduled workflows and live delivery.
The project uses Pytest for test execution, alongside Ruff for linting and formatting and Mypy for static type checking.
See the Testing Guide for the project’s testing workflow.
Documentation — docs/
The documentation is organized by purpose rather than being maintained as one large guide.
The documentation navigation is configured in
docs/docs.json.
Automation — .github/workflows/
GitHub Actions workflows automate scheduled and manually triggered operations.
The ingestion workflow runs the collection entry point and persists changes to the data repository.
The publishing workflow selects unpublished opportunities independently for Discord and Telegram, attempts delivery through both publishers, and persists destination-specific publication history.
Keeping orchestration in workflow definitions allows the application logic to remain executable independently of the CI environment.
See the GitHub Actions guide for setup and execution details.
Persistent Data — careers-data
Persistent operational state lives in the separate careers-data repository.
This separation prevents frequently changing generated data from being mixed with application source code. The workflows check out the data repository when they need to read or update its contents.
See Storage Architecture for the persistence model and the responsibilities of each file.
Project Configuration
The root configuration files support development, dependency management, and quality checks.pyproject.tomldefines project metadata, dependencies, and tool configuration.uv.lockrecords the resolved dependency versions.Makefileprovides convenient commands for development and validation.
Extending the Repository
When adding functionality, place it in the component that owns the relevant responsibility.- Add a new upstream integration under
sources/and its corresponding parser where required. - Add eligibility behavior under
filters/. - Extend employment classification in
employment.py. - Add company branding through the existing company registry and asset conventions.
- Add or update tests under
tests/. - Update the relevant documentation when behavior or developer workflows change.

