/framna-docs

📖❤️ Self-hosted web portal that centralizes OpenAPI documentation and facilitates spec-driven development, built with GitHub-based authorization.

Primary LanguageTypeScriptMIT LicenseMIT

Framna Docs logo

👋 Welcome to Framna Docs

Self-hosted web portal that centralizes OpenAPI documentation and facilitates spec-driven development, built with GitHub-based authorization.


🚀 Getting Started     👨‍🔧 How does it work?     👩‍💻 How can I contribute?     📖 Wiki

Framna Docs makes managing and previewing OpenAPI documentation a breeze, streamlining spec-driven development. With GitHub-based authorization, you can easily control who accesses your docs. Framna Docs comments on pull requests that tweak your OpenAPI specs, giving you preview URLs to ensure every update is well-reviewed.

Screenshot of Framna Docs

🚀 Getting Started

Please refer to the following articles in the wiki to get started with Framna Docs.

👨‍🔧 How does it work?

Framna Docs uses OpenAPI specifications from GitHub repositories. Users log in with their GitHub account to access documentation for projects they have access to. A repository only needs an OpenAPI spec to be recognized by Framna Docs, but customization is possible with a .framna-docs.yml file. Here's an example:

Framna Docs supports spec-driven development by requiring OpenAPI specs in GitHub repos, ensuring version control and peer review. When a pull request is opened, Framna Docs comments with links to preview the documentation:

Learn more from the Adding Documentation, Browsing Documentation, and Updating Documentation articles in the wiki.

👩‍💻 How can I contribute?

Pull requests with bugfixes and new features are much appreciated. We are happy to review PRs and merge them once they are ready, as long as they contain changes that fit within the vision of Framna Docs.

Clone the repository and consult the articles on running Framna Docs locally and contributing to get started contributing changes the project.

git clone git@github.com:shapehq/framna-docs.git

🔀 Git Workflow

Two following long-lived branches exist:

  • main: Stable/release branch meant for deployment to the production environment.
  • develop: Branch meant for deployment to a staging environment.

Do's 👍

  • Features are branched off from develop and merged back in using a PR when ready. Rebase or merge develop in to keep the feature branch up to date. Squash merge the feature branch into develop.
  • develop is merged into main whenever a new release is made. Only regular merge commits are allowed in this case. You do not need to bring develop up to date with main before merging.
  • A hotfix is applied by branching out from main. The hotfix branch must be merged into both main and develop.

Don'ts 🙅‍♂️

  • Never squash merge develop into main.

❤️ The Product of a Shape Weekend

Every year we go on Shape Weekend, three days where all employees in Shape get together for a hackathon to build amazing products. In 2023, a team of Shape developers with a passion for documentation and spec-driven development built Framna Docs and we've used it daily ever since!


Framna Docs is built with ❤️ by Shape in Denmark. Oh, and we are hiring 🤗