Introduction

Guides

Security

Setup with Demo Project

This guide will walk you through setting up a demo project to test Widgetbook Cloud. We'll use the groceries-demo repository as our example project.

Prerequisites

Before starting this guide, make sure you have:

  • An account for GitHub, GitLab, or Bitbucket
  • Access to Widgetbook Cloud
  • Basic knowledge of Git and your chosen Git provider

Steps

  • Clone the Demo Repository

    Since you're using GitHub, you can fork the repository directly:

    1. Navigate to the groceries-demo repository
    2. Click the Fork button in the top-right corner
    3. Select your personal account as the destination
    4. Wait for the forking process to complete
    5. Clone your forked repository:
    git clone https://github.com/YOUR_USERNAME/groceries-demo.git
    cd groceries-demo
    

    Use your personal GitHub account for forking, as business accounts might lack permission to connect repositories to Widgetbook Cloud.

  • Create a Widgetbook Cloud Workspace

    1. Navigate to Widgetbook Cloud
    2. Sign in with your account
    3. Click Create Workspace or use an existing workspace
    4. Enter a name for your workspace (e.g., "Demo Workspace")
    5. Click Create to finalize the workspace creation
  • Create a Widgetbook Cloud Project

    1. In your Widgetbook Cloud workspace, click Create Project
    2. Select GitHub as your Git provider
    3. If you haven't connected your GitHub account yet, click Connect GitHub and follow the authorization process
    4. Search for your forked groceries-demo repository
    5. Select the repository and click Import Project
    6. Wait for the project to be created and initialized
  • Get the API Key

    1. In your newly created Widgetbook Cloud project, navigate to Settings
    2. Find the API Key section
    3. Copy the API key

    Keep this API key secure. You'll need it to configure your CI/CD pipeline to upload builds to Widgetbook Cloud.

  • Add the API Key to Your Git Provider

    1. Go to your GitHub repository
    2. Navigate to SettingsSecrets and variablesActions
    3. Click New repository secret
    4. Set the name to WIDGETBOOK_CLOUD_API_KEY
    5. Set the value to your API key from Widgetbook Cloud
    6. Click Add secret
  • Re-run the CI/CD Pipeline

    1. Go to your GitHub repository
    2. Navigate to Actions tab
    3. Enable GitHub Actions for the forked repository
    4. Go to the Widgetbook Cloud Action and run it.
    5. Wait for the workflow to complete

    After the pipeline completes successfully, you should see a new build appear in your Widgetbook Cloud project's builds section.

  • Create a Component Change and Pull Request

    1. Create a new branch for your changes:
    git checkout -b feature/update-border-radius
    
    1. Change the border radius full in the lib/ui/foundation/radius.dart file to 0.
    class DesignSystemRadius {
      static const double none = 0;
      static const double xs = 4;
      static const double sm = 8;
      static const double md = 12;
      static const double lg = 16;
      static const double xl = 28;
      static const double xxl = 32;
      static const double full = 999; 
      static const double full = 0; 
    }
    
    
    1. Commit and push your changes:
    git add .
    git commit -m "Update radius"
    git push origin feature/update-border-radius
    
    1. Create a pull request (or merge request in GitLab):
    1. Go to your GitHub repository
    2. You should see a prompt to create a pull request for your recently pushed branch
    3. Make sure to target your forked repository as the base, not the original repository
    4. Click Compare & pull request
    5. Add a title and description for your PR
    6. Click Create pull request
  • Check the Pull Request in Widgetbook Cloud

    1. Wait for the CI/CD pipeline to complete for your feature branch
    2. Go to your Widgetbook Cloud project
    3. Navigate to the Pull Requests section
    4. You should see a new pull request
    5. Click on the pull request to see the visual differences between the base and feature branches
    6. Review the changes and approve or request changes as needed

    The review will show you exactly what changed visually between your feature branch and the main branch, making it easy to spot UI regressions or unintended changes.