HireTrust UI

HireTrust Platform

Enterprise-grade hiring platform designed to help HR teams manage hiring processes efficiently for client companies through structured, skill-based evaluation pipelines.

Overview

HireTrust focuses on true skills assessment through a structured, multi-stage evaluation pipeline. Instead of relying solely on resumes, the platform evaluates candidates through:

  • Language proficiency assessment (voice-based AI evaluation)
  • Basic fit evaluation (structured questionnaires with grading rubrics)
  • True Skill evaluation (coding challenges and technical assessments)
  • Experience & Presence evaluation (resume and LinkedIn profile analysis)
  • Structured interviews with AI-generated prompts
  • Comprehensive applicant reports and cover letters

Tech Stack

  • Monorepo: Nx Workspace
  • Frontend: Angular 20+ with SCSS and Tailwind CSS
  • UI Components: PrimeNG with FontAwesome icons
  • Backend: NestJS (modular monolith architecture)
  • Infrastructure: Firebase (Auth, Firestore, Cloud Functions, Hosting) and GCP
  • Infrastructure as Code: Terraform
  • Testing: Vitest (unit tests), Cypress (E2E tests)
  • CI/CD: GitLab CI/CD
  • Package Manager: Yarn 4

Project Structure

Example :
hire-trust/
├── apps/                    # Applications
│   ├── hosts/              # Frontend host applications (Module Federation)
│   │   ├── admin/          # Admin portal
│   │   ├── applicant/      # Applicant portal
│   │   ├── employer/      # Employer portal
│   │   ├── jobs/           # Public jobs portal
│   │   ├── support/        # Support portal
│   │   └── web/            # Marketing website
│   └── server/             # Backend applications
│       ├── api/            # Main API server
│       ├── schedulers/     # Scheduled tasks
│       └── sdk/            # SDK generation
├── dist/                   # Build artifacts (not in git)
│   └── api-docs/           # Static API Documentation site
├── libs/                    # Shared libraries
│   ├── api/                # Backend libraries
│   │   ├── features/       # Feature modules (domain-specific)
│   │   └── shared/         # Shared backend utilities
│   ├── data-access/        # Frontend data access layer
│   ├── shared/             # Framework-agnostic shared code
│   │   ├── models/         # Shared models/interfaces
│   │   └── utils/          # Shared utilities
│   └── ui/                 # Frontend UI libraries
│       ├── components/     # Reusable UI components
│       ├── features/       # Frontend features
│       └── modules/        # Frontend modules
├── infra/                   # Infrastructure as Code
│   ├── terraform/          # Terraform configurations
│   ├── scripts/            # Infrastructure automation scripts
│   ├── kubernetes/         # Kubernetes manifests (future)
│   └── elastic/           # Elasticsearch/ELK configs (future)
├── .cursor/                 # Cursor AI configuration
│   ├── rules/              # Project rules and guidelines
│   └── commands/           # Reusable commands
└── cypress/                # E2E test configurations

Getting Started

New developers: See docs/DEVELOPER_SETUP.md for a complete setup guide.

Quick Start

Example :
# Install dependencies
yarn install

# Verify setup
./scripts/verify-builds.sh

Infrastructure Setup

For detailed infrastructure setup, see:

Quick setup:

Example :
# Configure cloud authentication (one-time)
./infra/scripts/setup-gcp-auth.sh
./infra/scripts/setup-firebase-auth.sh

This will:

  • Authenticate with GCP for all projects (dev, staging, production)
  • Enable required APIs
  • Setup Application Default Credentials
  • Verify Firebase CLI authentication

Project Isolation & Safety

IMPORTANT: This workspace is configured to prevent accidental deployments to wrong GCP/Firebase projects.

Project IDs:

  • Sandbox/Dev: hiretrust-sandbox
  • Staging: hiretrust-staging
  • Production: hiretrust

Safeguards in place:

  1. .firebaserc - Explicit Firebase project aliases (dev, staging, production)
  2. .gcloudrc - gcloud project selection helper (mirrors .firebaserc)
  3. Explicit project flags - All scripts use --project flags instead of global gcloud config
  4. Terraform variables - Project IDs defined in terraform.tfvars per environment
  5. Migration scripts - Hardcoded project IDs in migrate.ts and seed.ts
  6. Environment files - Correct project IDs in environment.ts files
  7. direnv (.envrc) - Optional project-scoped env vars for GOOGLE_APPLICATION_CREDENTIALS, FIREBASE_PROJECT_ID, GOOGLE_CLOUD_PROJECT (recommended if you work across many GCP accounts/projects)

Before deploying, validate workspace:

Example :
./scripts/validate-workspace.sh [dev|staging|production]

Project-scoped credentials (recommended)

To keep Google credentials scoped to this repo only (no global shell profile leakage):

Example :
brew install direnv
# add to ~/.zshrc: eval "$(direnv hook zsh)"
cp .envrc.example .envrc
direnv allow

Best practices:

  • Always use scripts: ./scripts/deploy-*.sh <env>
  • Always use Terraform with explicit env: make plan ENV=dev
  • Always use Firebase aliases: firebase use dev (not project IDs)
  • For gcloud, use helper: source .gcloudrc && gcloud-use dev (or use explicit --project flags)
  • Check active project before manual commands: gcloud config get-value project or gcloud-current
  1. Create Terraform State Buckets
Example :
# Create GCS buckets for Terraform state storage
make create-state-buckets
  1. Configure Terraform Environment
Example :
# Setup Terraform for dev environment
make setup-terraform ENV=dev

# This creates terraform.tfvars from example
# Edit infra/terraform/environments/dev/terraform.tfvars if needed
  1. Initialize and Deploy Infrastructure
Example :
# Initialize Terraform
make terraform-init ENV=dev

# Review planned changes
make terraform-plan ENV=dev

# Apply infrastructure changes
make terraform-apply ENV=dev

Sandbox Infrastructure Setup

Before running the application, set up the sandbox infrastructure:

Example :
# Run automated setup script
bash scripts/setup-sandbox-infra.sh

# Or manually:
# 1. Initialize Terraform
make terraform-init ENV=dev

# 2. Validate configuration
make terraform-validate ENV=dev

# 3. Review plan
make terraform-plan ENV=dev

# 4. Apply infrastructure
make terraform-apply ENV=dev

Development

Example :
# Start all development servers
make dev

# Start individual services
make dev-admin      # Admin portal
make dev-applicant  # Applicant portal
make dev-employer   # Employer portal
make dev-api        # API server

Calendar OAuth (optional)

To enable Google/Outlook calendar connect and automatic interview event creation:

  • Required env vars:
    • CALENDAR_OAUTH_STATE_SECRET (random secret for signing OAuth state)
    • CALENDAR_TOKEN_ENCRYPTION_KEY (base64-encoded 32-byte AES key for encrypting tokens)
    • GOOGLE_CALENDAR_CLIENT_ID
    • GOOGLE_CALENDAR_CLIENT_SECRET
    • OUTLOOK_CLIENT_ID
    • OUTLOOK_CLIENT_SECRET

Users connect under Settings → Integrations and enable Auto sync on their availability rule.

Testing

Example :
# Run all tests
make test

# Run specific test suites
make test-unit      # Unit tests
make test-e2e       # E2E tests

Code Quality

Example :
# Lint code
make lint

# Format code
make format

SonarCloud analysis runs in GitLab CI for merge requests and main. Configure SONAR_TOKEN, SONAR_HOST_URL, SONAR_PROJECT_KEY, and SONAR_ORGANIZATION in GitLab CI/CD variables (see docs/GITLAB-CI-VARIABLES.md).

Infrastructure Management

Terraform Commands

Example :
# Initialize Terraform for an environment
make terraform-init ENV=dev

# Plan infrastructure changes
make terraform-plan ENV=dev

# Apply infrastructure changes
make terraform-apply ENV=dev

# Validate Terraform configuration
make terraform-validate

Database Migrations

Example :
# Run migrations for an environment
make migrate-dev        # Development
make migrate-staging    # Staging
make migrate-prod       # Production

# Or use nx directly
nx run migrations:migrate --env=dev
nx run migrations:migrate --env=staging --dry-run

Migrations are versioned and tracked in Firestore's _migrations collection. Each migration includes:

  • Version number
  • Up migration (applies changes)
  • Down migration (rollback, optional)

See libs/api/shared/infrastructure/firebase/migrations/README.md for details.

Seed Data

Example :
# Seed data for development/staging
make seed-dev           # Seed dev environment
make seed-staging       # Seed staging environment

# Clear existing data and seed
make seed-dev-clear     # Clear and seed dev
make seed-staging-clear # Clear and seed staging

# Seed specific collections
nx run migrations:seed --env=dev --collections=users,companies

Seed data ensures consistent test data across environments. See libs/api/shared/infrastructure/firebase/migrations/seed/ for seed data definitions.

Deployment

Example :
# Deploy to development
make deploy-dev

# Deploy to staging (requires confirmation)
make deploy-staging

# Deploy to production (requires explicit confirmation)
make deploy-production

GitLab CI/CD Runners

Zero-Cost Options

The project supports multiple runner configurations:

  1. GitLab.com Shared Runners (Free Tier)

    • 2000 CI/CD minutes/month free
    • No setup required
    • Already available on GitLab.com

  2. Self-Hosted Runner (Recommended)

    • Zero cost if using your own machine
    • Full control over environment
    • No time limits

  3. Hybrid Approach

    • Use shared runners for development
    • Use self-hosted for production deployments

Quick Setup

Example :
# Self-hosted runner is managed manually outside this repo.
# Ensure the runner is registered in GitLab with tags: hire-trust,nodejs

Runner setup is intentionally not automated via Terraform in this repo.

Environments

The platform supports three environments:

  • Development: hiretrust-sandbox (Project: 671888418700)
  • Staging: hiretrust-staging (Project: 1088795973754)
  • Production: hiretrust (Project: 230244526406)

Each environment has separate:

  • GCP/Firebase projects
  • Terraform state buckets
  • Configuration files
  • Custom domains (see below)

Custom Domains

Lower Environments (dev, staging):

  • Admin: admin.{env}.hire.astatinn.com
  • Applicant: applicant.{env}.hire.astatinn.com
  • Employer: employer.{env}.hire.astatinn.com
  • Jobs: jobs.{env}.hire.astatinn.com

Production:

  • Admin: admin.hire.astatinn.com
  • Applicant: applicant.hire.astatinn.com
  • Employer: employer.hire.astatinn.com
  • Jobs: jobs.hire.astatinn.com

Custom domains are configured via Firebase CLI after hosting sites are created. See infra/terraform/README.md for details.

CI/CD Pipeline

Single Branch Workflow: All environments use the main branch.

Pipeline Flow

  1. Push to main → Auto-deploy to Sandbox
  2. Manual trigger → Deploy to Staging (for QA)
  3. Manual trigger → Deploy to Production (creates release tag with semantic versioning)

Pipeline Stages

  1. Validate - Code quality checks (lint, terraform validate)
  2. Build - Compile applications (frontend and backend)
  3. Test - Run test suites (unit tests, E2E tests)
  4. Migrate - Run database migrations
    • Sandbox: Automatic after tests pass
    • Staging: Manual trigger
    • Production: Manual trigger
  5. Deploy - Deploy infrastructure and applications
    • Sandbox: Automatic after migrations
    • Staging: Manual trigger (for QA)
    • Production: Manual trigger (creates release tag)
  6. Release - Production rollback (manual)

Deployment Workflow

Sandbox (Auto-deploy):

  • Push to main → Runs validate, build, test
  • If all pass → Auto-runs migrations → Auto-deploys apps
  • No manual intervention required

Staging (Manual):

  • After sandbox validation, manually trigger:
    1. migrate:staging (if needed)
    2. deploy:apps:staging
  • Used for QA testing before production

Production (Manual with Versioning):

  • After staging QA approval, manually trigger:
    1. migrate:production (if needed)
    2. deploy:apps:production
  • Automatically:
    • Calculates semantic version from commit messages
    • Updates package.json version
    • Creates release tag (e.g., v1.2.3)
    • Commits version bump

Semantic Versioning

Version is automatically calculated from commit messages:

  • Major (1.0.0 → 2.0.0): Breaking changes (BREAKING CHANGE: or feat!:)
  • Minor (1.0.0 → 1.1.0): New features (feat:)
  • Patch (1.0.0 → 1.0.1): Bug fixes, refactors (fix:, perf:, refactor:)

Production Rollback

If production deployment has issues:

  1. Go to GitLab CI/CD → Environments → Production
  2. Click "Rollback" button
  3. System automatically:
    • Finds previous release tag
    • Builds and deploys that version
    • Restores production to previous state

Local Validation Before Push

Before pushing to GitLab, run validation locally:

Example :
# Run all checks (lint, build, test)
./scripts/pre-push.sh

# Or set up git hook (runs automatically on git push)
./scripts/setup-git-hooks.sh

This ensures lint, build, and test phases pass locally before pushing to GitLab.

See docs/CI-CD-WORKFLOW.md for detailed pipeline configuration and docs/GITLAB-CI-VARIABLES.md for required CI/CD variables.

Documentation

  • API Reference (Sandbox): https://docs.dev.hiretrust.me
  • API Reference (Production): https://docs.hiretrust.me
  • Latest Version: 1.5.30
  • Architecture: .cursor/rules/01-architecture.mdc
  • Coding Guidelines: .cursor/rules/02-coding-guidelines.mdc
  • Project Specifications: .cursor/rules/06-project-specifications.mdc
  • Infrastructure: infra/README.md
  • Terraform: infra/terraform/README.md
  • Transactional emails (SendGrid): docs/SENDGRID_SENDER_SETUP.md
  • Transactional email templates: docs/email/TEMPLATES.md

Building API Documentation

To build and deploy the interactive API documentation locally:

Example :
# Build the documentation static site
yarn build:api-docs

# Deploy documentation to current environment (dev/staging/production)
yarn deploy:api-docs <env>

The documentation is automatically built and deployed to Firebase Hosting via GitLab CI/CD on every push to main.

Contributing

Please read CODE_OF_CONDUCT.md and follow the project's coding guidelines in .cursor/rules/.

License

Copyright (c) 2025 Astatinn. All rights reserved.

Support

For questions or issues, please contact the development team.

Last Updated: 2026-01-03

results matching ""

    No results matching ""