{"id":44974289,"url":"https://github.com/fleek-platform/dashboard","last_synced_at":"2026-02-18T16:30:40.856Z","repository":{"id":277217316,"uuid":"887187340","full_name":"fleek-platform/dashboard","owner":"fleek-platform","description":"The Client's Dashboard is the interface for managing all Fleek platform services, which includes site deployments, functions and storage.","archived":false,"fork":false,"pushed_at":"2025-12-31T14:44:59.000Z","size":14614,"stargazers_count":2,"open_issues_count":5,"forks_count":0,"subscribers_count":1,"default_branch":"develop","last_synced_at":"2026-01-03T07:26:33.247Z","etag":null,"topics":["client-side","dashboard","fleek","fleek-hosting","reactjs","ui"],"latest_commit_sha":null,"homepage":"https://fleek.xyz/dashboard","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/fleek-platform.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-11-12T10:13:28.000Z","updated_at":"2025-12-31T14:33:29.000Z","dependencies_parsed_at":"2025-05-26T14:33:16.084Z","dependency_job_id":"7b5e28be-3860-4417-8174-58bc95897926","html_url":"https://github.com/fleek-platform/dashboard","commit_stats":null,"previous_names":["fleek-platform/dashboard"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/fleek-platform/dashboard","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fleek-platform%2Fdashboard","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fleek-platform%2Fdashboard/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fleek-platform%2Fdashboard/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fleek-platform%2Fdashboard/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/fleek-platform","download_url":"https://codeload.github.com/fleek-platform/dashboard/tar.gz/refs/heads/develop","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fleek-platform%2Fdashboard/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29585534,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-18T13:56:48.962Z","status":"ssl_error","status_checked_at":"2026-02-18T13:54:34.145Z","response_time":162,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["client-side","dashboard","fleek","fleek-hosting","reactjs","ui"],"created_at":"2026-02-18T16:30:39.926Z","updated_at":"2026-02-18T16:30:40.848Z","avatar_url":"https://github.com/fleek-platform.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"![](.repo/images/repo/banner.png?202411121019)\n\n# ⚡️Fleek-Platform Dashboard ⚡️\n\n[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-blue.svg)](https://conventionalcommits.org)\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![💍 Tester runner](https://github.com/fleek-platform/dashboard/actions/workflows/test-runner.yml/badge.svg)](https://github.com/fleek-platform/dashboard/actions/workflows/test-runner.yml)\n[![🔧 Build (dry-run)](https://github.com/fleek-platform/dashboard/actions/workflows/build-dry-run.yml/badge.svg)](https://github.com/fleek-platform/dashboard/actions/workflows/build-dry-run.yml)\n[![⚡️ Deploy Storybook (Staging)](https://github.com/fleek-platform/dashboard/actions/workflows/fleek-deploy-storybook.yml/badge.svg)](https://github.com/fleek-platform/dashboard/actions/workflows/fleek-deploy-storybook.yml)\n[![⚡️ Deploy Dashboard (Staging)](https://github.com/fleek-platform/dashboard/actions/workflows/fleek-deploy-staging.yml/badge.svg)](https://github.com/fleek-platform/dashboard/actions/workflows/fleek-deploy-staging.yml)\n[![⚡️ Deploy Dashboard (Production)](https://github.com/fleek-platform/dashboard/actions/workflows/fleek-deploy-production.yml/badge.svg)](https://github.com/fleek-platform/dashboard/actions/workflows/fleek-deploy-production.yml)\n\nThe Dashboard is the interface for managing all Fleek platform services, which includes site deployments, functions and storage.\n\n## Overview\n\n* [🎮 Environment Setup](#environment-setup)\n  - [Environment Variables](#environment-variables)\n  - [UI Test dev-server mode](#ui-test-dev-server-mode)\n  - [UI Terminate test static server](#terminate-ui-test-static-server)\n* [🤖 Install](#install)\n* [👷‍♀️Development](#development)\n  - [Code format](#code-format)\n  - [Changeset](#changeset)\n  - [Local Package Test](#local-package-test)\n  - [Regression Suite](#regression-suite)\n  - [Branch Deployment Matrix](#branch-deployment-matrix)\n  - [Distribution](#distribution)\n  - [Build](#build)\n  - [Preview build](#preview-build)\n* [⚡️ Performance](#performance)\n  - [React Performance checks](#react-performance-checks)\n* [💍 Tests](#Tests)\n  - [End-to-End](#end-to-end-e2e)\n  - [Unit tests](#unit-tests)\n  - [Component Functional Tests](#component-functional-tests)\n  - [CI/CD Runner](#cicd-runner)\n* [🛠️Generators](#Generators)\n  - [Sitemap](#sitemapxml)\n* [🖍️Component Library](#component-library)\n  - [Storybook](#storybook)\n* [🕷️Migration processes](#migration-processes)\n  - [Sync from monorepo](#sync-from-monorepo-process)\n* [🚀 Release to Production](#release-to-production)\n* [📖 Docs](https://fleek.xyz/docs)\n* [🙏 Contributing](#contributing)\n  - [Branching strategy](#branching-strategy)\n  - [Contributing](#conventional-commits)\n* [⏱️ Changelog](./CHANGELOG.md)\n\n## Requirements\n\n- Nodejs as runtime\n- NPM, Yarn to install the CLI as a client, or PNPM for development\n- Familiarity with text-based user interfaces, command-line interface (CLI)\n- Ports: UI (declared as NEXT_DEV_SERVER_PORT), Storybook (6006).\n\nYou'll also need to [setup](#environment-setup) the development environment.\n\n## Environment Setup\n\nFor developers looking to contribute to the User Dashboard, [clone](https://github.com/fleek-platform/dashboard) the repository and follow the [contribution guide](#contributing).\n\nOnce cloned, you'll have to set up the local development environment, e.g. to have access to the source-code, iterate, run tests and much more.\n\nFor runtime we utilize [Nodejs](https://nodejs.org/en/download) and [PNPM](https://pnpm.io/installation) as the package manager.\n\n### Environment Variables\n\nCreate a new file named .env in the root directory of your project. This file will store environment variables needed for local development.\n\n```sh\ntouch .env.development\n```\n\nOpen the .env.development file in a text editor and add the following:\n\n```sh\nNEXT_DEV_SERVER_PORT=\"3001\"\nNEXT_PUBLIC_SDK__AUTHENTICATION_URL=\"https://graphql.service.fleek.xyz/graphql\"\nNEXT_PUBLIC_UI_FLEEK_REST_API_URL=\"https://api.fleek.xyz\"\nNEXT_PUBLIC_UI__DYNAMIC_ENVIRONMENT_ID=\"de23a5f0-aaa5-412e-8212-4fb056a3b30d\"\nNEXT_PUBLIC_UI__GTM_ID=\"GTM-5RC2N5H\"\nNEXT_PUBLIC_UI__POSTHOG_HOST=\"https://us.i.posthog.com\"\nNEXT_PUBLIC_UI__POSTHOG_KEY=\"phc_RJhBMFHIZxwd361q6q9LZxDvSAta0F56mXQo3An307y\"\nNEXT_PUBLIC_UI__SITE_SLUG_DOMAIN=\"on-fleek.app\"\nNEXT_PUBLIC_UI__STRIPE_PUBLIC_KEY=\"dummy\"\nNEXT_PUBLIC_UI__ZENDESK_PROXY_API=\"https://support-prod-eu-lon-1-01.flkservices.io\"\nNEXT_PUBLIC_ZENDESK_PROXY_HOSTNAME=\"support-prod-eu-lon-1-01.flkservices.io\"\nNEXT_PUBLIC_UI__UPLOAD_PROXY_API_URL=\"https://uploads.service.fleek.xyz\",\nNEXT_PUBLIC_UI__INTERNAL_IPFS_STORAGE_HOSTNAME=\"storage-ipfs.internal.fleek.xyz\"\nNEXT_PUBLIC_WEBSITE_URL=\"https://fleek.xyz\"\nNEXT_PUBLIC_DASHBOARD_BASE_PATH=\"/dashboard\"\nNEXT_PUBLIC_AGENTS_AI_PATH=\"/eliza\"\nNEXT_PUBLIC_ALLOW_LANDING_PAGE_LOGIN=\"true\"\nNEXT_PUBLIC_BILLING_FREE_PLAN_DEPRECATION_DATE=\"2025-04-17\"\nNEXT_PUBLIC_UI__COMMIT_HASH=\"dev.hash\"\n```\n\n💡 The variables above point to our production environment, the same you interact with as an end-user. Internal development team have access to private environments. Because the environment most users have access to is production which mismatches the filename .env.development this can be replaced by `.env` if that's sounder to you.\n\n\u003e [!WARNING]\n\u003e Set the NODE_ENV variable to select the corresponding environment file (.env*), e.g. NODE_ENV=\"production\" would read the file .env.production\n\u003e Keep it simple, name the file to the corresponding environment like .env.\u003cNODE_ENV\u003e\n\u003e The test runner ignores .env.local.*\n\n\u003e [!IMPORTANT]\n\u003e The build process requires the environment variables to be populated. If you're building the project locally, you should create a .env.production, otherwise it'll fail to locate the environment variables.\n\nTest specific environment variables must be setup in the location `.tests/.env`.\n\n```sh\nNEXT_DEV_SERVER_PORT=3001\nUI_TEST_HTTP_SERVER_PORT=3001\nUI_TEST_DEV_SERVER_MODE=\"\" \nUI_TEST_DEV_SERVER_STATIC_PATH=\"out\"\nUI_TEST_DEV_SERVER_HOSTNAME=\"localhost\"\n```\n\n### UI Test dev-server mode\n\nTo set the E2E tests to use the static build, set the UI_TEST_DEV_SERVER_MODE to \"build\". Leave empty to default to the next dev server.\n\nThe \"build\" mode can be useful for users on lower specification machines, e.g. test timeouts. Unfortunately, the Nextjs library dev server consume a lot of resources.\n\nWhen using the \"build\" mode, a new build has to be processed for every source-code change. Otherwise, you'll be testing the wrong source-code output version.\n\nConsequently, due to the amount of time the build process takes to complete, it's not suitable for testing continuous contributions.\n\n```sh\nUI_TEST_DEV_SERVER_MODE=\"build\"\n```\n\n### UI Test dev-server ports\n\nIt's recommended to use the default port 3001. Due to intercepting network calls (mocking) and reusability of call data information across contributors. For this reason, when opting for \"build\" mode, set the UI_TEST_HTTP_SERVER_PORTas 3001. You can use a different port for the nextjs dev server, e.g. 1234.\n\n```\nUI_TEST_HTTP_SERVER_PORT=3001\nUI_TEST_DEV_SERVER_MODE=\"build\"\nNEXT_DEV_SERVER_PORT=1234\n```\n\n\u003e [!WARNING]\n\u003e To use the default nextjs for testing, you must update the NEXT_DEV_SERVER_PORT to the recommended default port number 3001. Disable the \"build\" mode and you must restart the servers.\n\n\u003e [!NOTE]\n\u003e As a result of the \"build\" processing time, which's long, build requests have to be executed manually. Learn how to build [here](#build)\n\n### Terminate UI test static server\n\nWhen the UI test static server's running, there might be cases you want to shut it down, e.g. free up the port 3001 for some other process.\n\nTo terminate the UI test static server gracefully by running:\n\n```sh\npnpm test:terminate_http_server\n```\n\nNow that you've learned to setup the development environment, you can proceed to [install](#install) the project dependencies.\n\n## Install\n\nStart by installing the project dependencies:\n\n```sh\npnpm i\n```\n\n## Development\n\nRun a local development server by executing the command:\n\n```sh\npnpm dev\n```\n\n\u003e [!NOTE]  \n\u003e The project's built with Nextjs, that might be familiar to you.\n\nIt'll try to start the development server. Once ready, you should get a local address in the output.\n\nFor example, let's say it was bound to the default port 3000, you'd get:\n\n```sh\n- Local:        http://localhost:3000\n```\n\n\u003e [!WARNING]\n\u003e Consider the configured port declared as NEXT_DEV_SERVER_PORT\n\u003e If the port 3000 is not free on execution a different port's utilized. Check the output for the correct address, please!\n\nOpen the address [http://localhost:3000](http://localhost:3000) in your favourite development browser.\n\n### Build\n\nBuil the project by executing the command:\n\n```sh\npnpm run build\n```\n\nOur build process outputs static files to:\n\n```sh\nout\n```\n\n\u003e [!WARNING]\n\u003e The build process requires the environment variables to be populated. If you're building the project locally, you should create a .env.production, otherwise it'll fail to locate the environment variables.\n\nThe output directory is where all public files are stored and published.\n\nOptionally, if you need to override the environment variable defined values create a `defined_overrides.json` file in the public directory.\n\n```sh\ntouch public/defined_overrides.json\n```\n\nDeclare any overrides for [src/defined.ts](./src/defined.ts) as follows:\n\n```sh\nNEXT_PUBLIC_WEBSITE_URL=\"https://custom.hostname\"\n```\n\nYou may only find this useful to control the prebuild distribution package, e.g. when hosting the application alongside other, such as [website](https://github.com/fleek-platform/website) where you'd need to control the environment to play along. You'd also have to put the file in the distribution files.\n\n### Preview build\n\nTo preview the build locally, you can run the command:\n\n```sh\npnpm preview\n```\n\nA HTTP server will serve the build output.\n\n### Code Format\n\nFormatting and linting are facilitated by [BiomeJS](https://biomejs.dev). Configuration details can be found in:\n\n```\nbiome.json\n```\n\nTo format source code and apply changes directly in the file:\n\n```sh\npnpm format\n```\n\nFor checking source code formatting only:\n\n```sh\npnpm format:check\n```\n\nTo lint and apply changes directly in the file:\n\n```sh\npnpm lint\n```\n\nFor lint checks only:\n\n```sh\npnpm lint:check\n```\n\nTo both format and lint source code (with writes):\n\n```sh\npnpm format:unsafe\n```\n\n### Changeset\n\nManage the versioning of changelog entries.\n\nDeclare an intent to release by executing the command and answering the wizard's questions:\n\n```sh\npnpm changeset:add\n```\n\n### Local Package Test\n\nSince npm link is a command-line tool for symlinking a local package as a dependency during development. It is commonly used for testing packages before publishing them. But it's common to cause confusion and unexpected behaviour.\n\nInstead of using `pnpm link` for local package testing, use the following command, that's closer to release install.\n\n```sh\npnpm generate:local_package\n```\n\nOnce successful, the console will display an install command that you can copy and run in your project.\n\nHere's an example that uses npm:\n\n```sh\nnpm i --no-save \u003cGENERATED_FILE_PATH\u003e\n```\n\n\u003e [!WARNING]\n\u003e Remove concurrent package name from package.json, e.g. @fleek-platform/dashboard. The local install doesn't save or modify the package.json. The package.json and lockfiles are only for existing registry versions. You might have to run the clean command to remove any conflicting packages from node_modules, locks, etc.\n\nAlternatively, if you're using an npm-compatible package manager like pnpm, avoid saving or modifying the lock file, e.g:\n\n```sh\nnpm_config_save=false npm_config_lockfile=false pnpm i \u003cGENERATED_FILE_PATH\u003e\n```\n\nAnother option is to use the GitHub registry to push any packages you might want to test. Find more about it [here](#override-organisation-registry).\n\n### Regression Suite\n\nRegression in software testing refers to when a previously working feature stops working after new changes are made. When contributing make sure that changes are healthy and cause issues.\n\nLearn how to run and write tests [here](#tests).\n\n### Branch Deployment Matrix\n\nThis table shows the corresponding deployment URLs for each branch. Note that the availability and state of each URL depends on successful CI/CD build and deployment.\n\n⚠️ The URLs below may be temporarily unavailable during deployments or if a build fails.\n\n```\nBranch              |  URL\n----------------------------------\ndevelop (latest)    |  https://fleek-dashboard-staging.fleeksandbox.xyz\ndevelop (storybook) |  https://fleek-dashboard-storybook.on-fleek.app\nmain                |  https://fleek-dashboard-production.on-fleek.app\n```\n\n### Distribution\n\nTo enable support for redirects, single-page-applications, custom 404 pages on IPFS-backed hosting, we use f the [_redirects](https://docs.ipfs.tech/how-to/websites-on-ipfs/redirects-and-custom-404s/#evaluation).\n\nAlso, set the environment variable `NEXT_PUBLIC_BASE_PATH`, as the base forward path in `_redirects`:\n\n```\n/* /dashboard/index.html 200\n```\n\n## Performance\n\nThe following are performance tools to help identify rendering bottlenecks and component inefficiencies.\n\n### React Performance checks\n\nWe use [react-scan](https://github.com/aidenybai/react-scan) to help detect performance issues in the dashboard (react application). The process will help identify unnecessary renders that cause the application to become slow. Learn more [here](https://github.com/aidenybai/react-scan).\n\nTo spin up an interactive and isolated browser instance run the following command:\n\n```sh\npnpm run perf:scan\n```\n\n## Tests\n\nThe project has two category of tests:\n\n- End-to-End (e2e) built on playwright to facility testing the UI/UX interface. The network calls are mocked to facilitate rapid development and focus on the interface;\n- Unit tests, which assert pure functions, e.g. data transformations, calculations, etc, a separate concern over the presentation;\n\nYou can run all tests by executing the command:\n\n```sh\npnpm run test\n```\n\nAlternatively, you can inspect the available tests in the package.json scripts section.\n\nFor example, you can launch end-to-end tests, on a chrome browser:\n\n```sh\npnpm run test:ui\n```\n\nRun the E2E test suite\n\n```sh\npnpm run test:e2e\n```\n\nRun the unit tests\n\n```sh\npnpm run test:unit\n```\n\nRun the component function tests\n\n```sh\npnpm run test:component\n```\n\n### Good practices\n\nHere are some recommendations when writing tests.\n\n#### End-to-end (E2E)\n\n- Block any unnecessary network requests, e.g., third-party services, such as analytics, etc\n- Use headless mode for fast feedback\n- Prepare and clean data or state for each test\n- Prioritize user flows, e.g. prefer role selection instead of specifying implementation details such as ID, Class, or element names (DOM locators)\n- Prefer tools provided by Playwright\n- Tests should be independent and isolated, e.g. avoid sharing state across test cases depending on others\n- Use the mode `Browser/UI` to see the tests in actions to see how the application render, inspect network logs, etc\n- Tests should have the ability to run concurrently, e.g., you'd rather have 5 workers computing instead of waiting sequentially to save you time\n- Mock API calls providing the expected data structure in the response, to prioritize testing the interface, e.g., you're testing that the user-interface corresponds to the user-journey goals NOT the service-side availability\n- Handle exceptions gracefully, e.g., test cases where the API response fails, etc\n- Avoid writing tests for static elements that's useless to the end-user\n- Avoid placing timeouts in the test\n\n#### Unit tests\n\nUnit tests should be small tests that check individual parts of code for correctness. Ideally, functions tested with unit tests should be:\n\n- Pure, meaning their output depends only on their inputs, with no side effects. This makes them predictable and easier to test\n- Each test should run independently, without relying on other tests\n- Test One Thing Per Test: Focus each test on verifying a single behavior or functionality\n- Replace external dependencies (e.g., databases) with mock objects\n- Write simple, concise tests for easier debugging and maintenance, e.g. prefere storytelling\n\n\n#### Component Functional tests\n\nThe terminology \"Component Function tests\" is used to describe unit tests for components. You can refer to it as unit-tests, but when communicating component functionality, it's our preference to refer to it as \"Component Functional tests\". It avoids confusion.\n\n\u003e [!WARNING]\n\u003e Do not confuse it with [Component testing](https://storybook.js.org/blog/component-testing/) as promoted by Storybook's team. The Component Function tests at Fleek's Frontend has a very particular meaning in the context's they're used and serves to communicate efficiently.\n\nIdeally, components should be tested in isolation (unit). Events or inputs should reproduce expected behaviour and output. Here's a break-down:\n\n- Focus on Component Behavior\n- Tests must be user-oriented, e.g. validate a component feature from a user's perspective\n- Ensure a component work as intended before integration with other components or the application\n- Avoid testing internal implementation details like state or private functions\n- Identify and prioritize testing the most common and critical component behaviors\n- Ensure all major user interactions and outcomes are tested\n- Props should be as realistic as possible to reflect how the component will be used in production\n- Test interactions (clicks, typing, form submissions) as closely as possible to real user actions\n- Simulate user actions or lifecycle changes\n- Ensure visual changes like showing/hiding elements are validated\n- Test only one behavior or aspect per test case, e.g. avoid long tests that cover multiple, unrelated scenarios\n- Do not rely on snapshots for dynamic or interactive components\n- Ensure tests are fast enough for regular execution\n- Update tests when refactoring or introducing new features\n\n#### CI/CD Runner\n\nOn CI/CD runners, low specs cause inconsistent runs to mitigate any inconsistency playwright's team recommends running in a single worker [CI/Workers](https:playwright.dev/docs/ciworkers).\n\nNote that launching a [large](https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners), e.g. `macos-latest-xlarge` runner is more efficient but increases cost dramatically.\n\n## Generators\n\n### Sitemap.xml\n\nGenerate a sitemap by executing the command:\n\n```sh\npnpm run generate:sitemap\n```\n\n## Component Library\n\nThe component library provides a collection of ready-to-use components. We use [Storybook](#storybook) to showcase and document our components.\n\n### Storybook\n\nStart the storybook development server:\n\n```sh\npnpm storybook\n```\n\nTo build a static version:\n\n```sh\npnpm storybook:build\n```\n\nWhen committing to develop branch, a new build is deployed to [https://fleek-dashboard-storybook.on-app.xyz](https://fleek-dashboard-storybook.on-app.xyz).\n\n## Migration processes\n\nTo assist with migrating from an outdated repository and updating our workflows, we've outlined the following processes.\n\n### Sync from monorepo process \n\nThe \"sync from monorepo\" process automates the transfer of source code files from the deprecated monorepo to the new repository. It only copies files created or changed in the range of commit hash from to the latest HEAD version. By using this process, you reduce the number of files to synchronize to only what has been changed. Reducing the number of files to verify, due to cases where the current repository might have progressed containing changes that do not exist in the source repository.\n\nBefore you start, check the original repository commit hash you want to pick changes from. The commit hash you choose is exclusive. It marks a point in history but doesn't include its files. To sync files, use the previous commit hash. This creates a range for selective file inclusion, allowing you to choose exactly which changes to apply.\n\n```sh\npnpm run migrate:sync_from_monorepo\n```\n\n## Release to production\n\nYou can release to production following a linear strategy. This assumes that the convention \"main\" branch is of linear history and is a subset of the \"develop\" branch commit history. For example, the team is happy to have \"develop\" as where the latest version of the project exists, that \"main\" shouldn't diverge and only contain commits from \"develop\".\n\nUse-case examples:\n\n- The team has merged some feature branches into develop identified as commit hash \"abc123\" and want to release upto to the commit history hash \"abc123\" onto \"main\". By doing this they expect the build process to occur and deploy into the Fleek Platform\n- The team has merged several feature branches into develop identified as commit hashes `commitFeat1`, `commitFeat2` and `commitFeat3` by this historical order. It's decided to release everything in commit history until `commitFeat1`, but not `commitFeat2` and `commitFeat3`. Although, it'd be wiser to keep the feature branches in pending state as \"develop\" should always be in a ready state for testing and release as the team may want to release some quick hotfixes, etc\n\nTo release to production open the actions tab [here](https://github.com/fleek-platform/dashboard/actions/workflows/release-by-develop-hash.yml).\n\nSelect the \"🚀 Release by develop hash\" job in the left sidebar. Next, select the \"Run workflow\" drop-down and provide the required details.\n\n## Contributing\n\nThis section guides you through the process of contributing to our open-source project. From creating a feature branch to submitting a pull request, get started by:\n\n1. Fork the project [here](https://github.com/fleekxyz/cli)\n2. Create your feature branch using our [branching strategy](#branching-strategy), e.g. `git checkout -b feat/my-new-feature`\n3. Run the tests: `pnpm test`\n4. Commit your changes by following our [commit conventions](#conventional-commits), e.g. `git commit -m 'chore: 🤖 my contribution description'`\n5. Push to the branch, e.g. `git push origin feat/my-new-feature`\n6. Create new Pull Request following the corresponding template guidelines\n\n### Branching strategy\n\nThe develop branch serves as the main integration branch for features, enhancements, and fixes. It is always in a deployable state and represents the latest development version of the application.\n\nFeature branches are created from the develop branch and are used to develop new features or enhancements. They should be named according to the type of work being done and the scope of the feature and in accordance with conventional commits [here](#conventional-commits).\n\n### Conventional commits\n\nWe prefer to commit our work following [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) conventions. Conventional Commits are a simple way to write commit messages that both people and computers can understand. It help us keep track fo changes in a consistent manner, making it easier to see what was added, changed, or fixed in each commit or update.\n\nThe commit messages are formatted as **[type]/[scope]**\nThe **type** is a short descriptor indicating the nature of the work (e.g., feat, fix, docs, style, refactor, test, chore). This follows the conventional commit types.\n\nThe **scope** is a more detailed description of the feature or fix. This could be the component or part of the codebase affected by the change.\n\nHere's an example of different conventional commits messages that you should follow:\n\n```txt\ntest: 💍 Adding missing tests\nfeat: 🎸 A new feature\nfix: 🐛 A bug fix\nchore: 🤖 Build process or auxiliary tool changes\ndocs: 📝 Documentation only changes\nrefactor: 💡 A code change that neither fixes a bug or adds a feature\nstyle: 💄 Markup, white-space, formatting, missing semi-colons...\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffleek-platform%2Fdashboard","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffleek-platform%2Fdashboard","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffleek-platform%2Fdashboard/lists"}