Week #4 #

Testing and QA #

Vladimir wrote tests and generated test coverage for core functionality of the project:

• minio(needed as core moodle files storage)
• search flow - ensure proper processing results from ml, proper fallback to mongo search, proper mongo results processing. Also he implemented github workflow to run tests in push/PR, so only tested code can be placed in the repository (see commit).

Evidence of test execution #

CI logs link

CI/CD #

The project uses GitHub Actions for automated building, testing, and deployment of all components:

Website (Frontend) #

• Build & Deploy:

  Workflow: .github/workflows/deploy.yaml

  • Builds static files with pnpm

  • Deploys via appleboy/scp-action to Innohassle server

  • Supports:

    • staging deployment by default

    • capstone deployment from a specific branch

  • Files served via Nginx under:

    https://search.innohassle.ru

• Lint & Format Checks:

  Workflow: .github/workflows/lint.yaml

  • Runs ESLint and Prettier on every push and pull request

Search (Backend) #

• Build & Deploy (Docker):

  Workflow: .github/workflows/build-docker.yaml

  • Builds Docker image and publishes to GitHub Container Registry (ghcr.io)

  • Manual or main branch deploy triggers SSH-based deployment to Innohassle server

  • Runs a custom server-side deployment script to restart API

  • API accessible via:

    https://api.innohassle.ru/search/staging-v0

• Pre-commit Checks:

  Workflow: .github/workflows/pre-commit.yaml

  • Runs pre-commit hooks with ruff.

  • Uses Poetry with local virtual environments

• Automated Tests:

  Workflow: .github/workflows/run-tests.yaml

  • Runs pytest on push and pull requests

  • Uses Poetry for dependency management

  • Copies settings.example.yaml for test configuration

ML Component #

• Deployment:

  Workflow: .github/workflows/build-docker.yaml (deploy-ml job)

  • SSH deployment to a GPU-enabled server

  • Runs server-side deployment script to restart Python processes

Links to CI/CD configuration files #

Backend workflow link

Frontend workflow link

Deployment #

Staging and production #

Our staging environment meets production requirements: domain name, public access, real data, integration with real external services

• Website: https://search.innohassle.ru

• API: https://api.innohassle.ru/search/staging-v0

• Static files and API deployed to the Innohassle server (Innopolis)

• ML service connects to a separate GPU server, restarts after updates

The project launch for end users will be available at https://innohassle.ru

Backend #

Azaliia implemented the handling of maps resources along with a dedicated MongoDB schema, added a specialized function to handle the unique transformation of maps data into LanceDB attachments (see commit). Azaliia also made changes to the backend so that by default the search occurs across all resources (see commit)

To make search results more specific, it was necessary to refactor the parsers so that mongo entries were small parts of the site pages, namely anchors. To do this, Anna refactored the clubs parser for campuslife (see commit), the campuslife general information parser (see commit), and the eduwiki parser (see commit). Anna also did team management (see the kanban board, search project), and reviewed all the PRs, merging them into the main (debug commit #1, #2, for example).

Aliia added a new resource to the search pipeline: wrote a parser for the Innopolis residents’ website, added its processing to the backend and ml (see commit)

Frontend #

Aliia added search example below the search field (see commit) and added response_types filtration and preview text in SearchResult (see commits #1 and #2)

ML #

Sofia fixed the duplication of fragments during the search (see commit and commit), and the text preview was also optimized for XML tags (see commit). In addition, a full-fledged stack for ask was created, including the definition of Pydantic models, the implementation of a FastAPI endpoint, integration with the RAG search system, and interaction with an external LLM via OpenRouter (see commit).

Azaliia also created a dataset to evaluate the performance of the search.

Overall progress #

Overall, this week we improved the user experience (see the hints for entering the search bar; the link to the resource is valid on the entire area of ​​the search answer card; the design is adapted for intuitive clicking on the link), clarified the resources (divided the sites into different cards using anchors), added previews to the sites (see the description of the site at the bottom of the card)

Vibe Check #

The team is happy with the current progress of the project, we have done a lot of work and our results are even ahead of our initial expectations. Need: We should make sure that all areas of development are covered and think about lightweight features that we can implement to make our progress more visible. Communication within the team is effective and we all feel heard.

Weekly commitments #

Individual contribution of each participant #

Plan for Next Week #

• Improve search for new resources (we will need to make changes to the parsers, perhaps clarify the model prompt)
• Link the frontend of the ask functionality with the backend
• Rewrite the project to uv (faster than poetry, better resolves dependencies, more convenient CI/CD)
• Continue to expand the list of resources for search
• Start working on act (write more specific user stories with resources and interaction architecture, explore available technologies)

Confirmation of the code’s operability #

!!! The working code in the backend repository is in the main branch, and in the frontend repository in the capstone branch (difficulties due to automatic deployment)

• In working condition.
• Run via docker-compose (or another alternative described in the README.md).