FlowForge is your interactive sidekick for building and managing GitHub workflows effortlessly. With a playful drag-and-drop interface, it transforms complex automation into a delightful experience.
Features:
- 🎨 Visual Workflow Builder: Design workflows with an intuitive drag-and-drop interface—no coding required!
- 🔧 Custom Node Integration: Add personalized nodes to tailor workflows to your unique needs.
- ✅ Real-time Validation: Get instant feedback to ensure your workflows are error-free before deployment.
- 🔗 Seamless GitHub Integration: Connect directly to your GitHub repositories for smooth workflow management.
Tech Stack:
- Next.js: React framework for server-side rendering.
- Tailwind CSS: Utility-first CSS framework for rapid UI development.
- Shadcn/UI: Reusable components built with Radix UI and Tailwind CSS.
- Drizzle ORM: TypeScript-first ORM for Node.js.
- React Flow: Library for building node-based interfaces.
- Zustand: Fast and scalable state management for React.
Getting Started:
-
Clone the Repository:
git clone https://github.com/cybertron288/flowforge.git
-
Navigate to the Project Directory:
cd flowforge
-
Install Dependencies:
yarn install
If you're using npm, run
npm install
. -
Set Up Environment Variables:
Duplicate the .env.example file and rename it to .env.local.
Update the environment variables in .env.local as needed.
-
Run Database Migrations:
npx drizzle-kit migrate
-
Start the Development Server:
yarn dev
Open http://localhost:3000 in your browser to access the application.
We love contributions! To get started:
-
Fork the repository.
-
Create a new branch:
git checkout -b feature-name
-
Make your changes.
-
Commit your changes:
git commit -m 'Add feature description'
-
Push your branch:
git push origin feature-name
-
Create a pull request.
Make sure to include a description of your changes and any relevant information.
I use the following convention:
type: subject
body
The goal of this convention is to communicate clear goal.
The types are based on our GitHub label:
fix
– When fixing an issue.chore
– When doing some cleanup, working on tooling, some refactoring.doc
– When writing documentation.feat
– When working on a feature.
The subject of a commit should be a summary of what the commit is about. It should not describe what the code is doing:
feat: what the feature is
fix: what the problem is
chore: what the PR is about
doc: what is documented
Examples:
feat: introduce combobox primitive
fix: popover is not correctly aligned
chore: refactor checkbox to use radix
doc: update storybook for button
⚠️ For afix
commit the message should explain what the commit is fixing. Not what the solution is.
Use kebab-case
to name your branches: prefix/branch-name-something
Branch naming convention
fix
: When fixing an issue:fix/some-bug
chore
: When doing some cleanup, working on tooling, some refactoring:chore/code-refactoring
docs
: When writing documentation:doc/documentation-subject
feat
: When you are working on a feature. Start by creating afeat/name-of-feature
branch & create tasks branches with the feature name as prefix: