[SwarajKeshari]

Description

Closes #1050

This PR implements the backend support for the revamped OpenLogo release page.

What this PR includes

• Syncs newly published GitHub Releases into MongoDB.
• Adds an API to fetch available release versions.
• Adds an API to fetch release details for a specific version.
• Adds a historical release seed script for populating local or production databases.
• Adds strict release-body parsing and validation based on the release template.
• Adds tests for release parsing, validation, repository, service, controller, and seed functionality.

Testing note: This backend branch is intended to be tested together with the frontend release-page revamp branch:
feat/issue-1050-revamp-release-page-ui

---

Local Testing

1. Test the frontend and backend together

The frontend and backend changes are available on separate branches. You can use Git worktrees to have both branches checked out simultaneously.

Backend

From your main OpenLogo worktree:

git fetch openlogo

git worktree add ../openlogo-backend \
  openlogo/feat/issue-1050-implement-revamped-release-page-backend

Then:

cd ../openlogo-backend
pnpm install

Configure the required backend environment variables in:

packages/app/.env

Start the backend:

pnpm --filter app start

The backend should be available at:

http://localhost:5000

Frontend

In the original OpenLogo worktree:

git fetch openlogo
git checkout feat/issue-1050-revamp-release-page-ui

Install dependencies if required:

pnpm install

Configure the required frontend environment variables and start the frontend:

pnpm --filter ui start

The frontend should be available at:

http://localhost:3000

Make sure the frontend is configured to use the locally running backend at:

http://localhost:5000

Once both applications are running, open the frontend and verify that the revamped release page renders properly.

The release page requires release data to be present in the local MongoDB database. Follow the steps below to seed the data.

2. Seed release data locally

The historical release seed script can be used to populate the configured MongoDB database.

From the repository root:

pnpm --filter app seed:releases

After seeding, verify that release versions are available through the API:

curl http://localhost:5000/api/releases/versions

Then fetch a specific release:

curl http://localhost:5000/api/releases/0.8.0

Replace 0.8.0 with any version returned by the /api/releases/versions endpoint.

The seed script can also be used when populating the production database, with the appropriate production database configuration.

3. Test the release APIs

Get available release versions

GET /api/releases/versions

Example:

curl http://localhost:5000/api/releases/versions

Get a specific release

GET /api/releases/:version

Example:

curl http://localhost:5000/api/releases/0.8.0

The release data returned by these APIs is read from MongoDB and is consumed by the revamped release page.

4. Testing the GitHub Release Sync Workflow

The GitHub Release synchronization workflow can be tested safely using a personal fork instead of creating test releases in the main repository.

4.1 Fork the Repository

Fork the OpenLogo repository and clone your fork locally. Push this backend branch to your fork if required.

4.2 Configure the Required Secrets

Create a separate database in MongoDB Atlas for testing the release synchronization workflow. This ensures that test releases do not affect the project's shared database.

Then, in your fork:

1. Create a MongoDB Atlas cluster/database for testing.
2. Copy the MongoDB connection string for the test database.
3. Add the connection string as the required GitHub Actions repository variable/secret used by the release synchronization workflow.
4. Configure any other secrets required by the workflow.

4.3 Create a Test Release

Create a GitHub Release in your fork using the release template format.

For example:

### 📝 Features

#### #1042 | Test Release Entry

Test release synchronization.

> Contributors: @your-username

Use a valid PR number and GitHub username from your fork/repository when testing GitHub entity validation.

4.4 Publish the Release

Publish the release and verify the workflow execution from the Actions tab.

The workflow should:

• Parse the release body.
• Validate the release format.
• Validate the referenced GitHub entities.
• Store the release data in MongoDB.

5. Test validation failures

Create another release with an invalid format, for example:

### 📝 Features

#### #1042 | Invalid Entry

Missing contributors field.

The workflow should fail with a validation error and should not insert the invalid release into the database.

Other invalid cases covered by the parser tests include:

• Missing release entries.
• Unsupported category headings.
• Incorrect category heading levels.
• Missing descriptions.
• Invalid Contributors format.
• Duplicate Contributors fields.
• Content after the Contributors field.
• Invalid contributor usernames.

What type of PR is this? (Check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📄 Documentation Update
• 👨‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🛠️ CI/CD

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
openlogo-prod-web	Ready	Preview	Sep 21, 2026 6:19pm UTC
openlogo-staging-web	Ready	Preview	Sep 21, 2026 6:19pm UTC

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE