humm_cli 1.0.10

humm_cli: ^1.0.10 copied to clipboard

humm #

Humm Flutter CLI package - a tool for project management.

Getting Started 🚀 #

To activate the CLI, run this command in the project's root folder:

"dart pub global activate --source path ." or "dart pub global activate humm"

Usage #

Release #

# Basic release command
humm release

# Options
humm release --version $version        # Set a specific version (default: increment by 1)
humm release --branch $branch              # Specify branch (default: develop)
humm release --tag-prefix $tag_prefix      # Add a custom tag prefix
humm release --build-number $build_number        # Set a specific build number

Changelog #

# Generate production changelog
humm prod_changelog --version $version # Generate changelog for a specific version

# Get changelog for a specific version
humm changelog $version                # Example: humm changelog 7.11.2

Slack Notifications #

# Notify Slack about a changelog, custom message or both.

#! Remember to set environment variables before use.
SLACK_WEBHOOK = WEBHOOK_URL 

humm notify_slack --appName PROJECT_NAME

# Notify Slack with a custom message
humm notify_slack --appName PROJECT_NAME --message "Custom message"

# Set flag --messageWithChangelog true to send custom message with changelog.
humm notify_slack --appName PROJECT_NAME --message "Custom message" --messageWithChangelog true

# Pass url for slack webhook directly
humm notify_slack --appName PROJECT_NAME --url "https:/customurl.com"


# Notify Slack about an error
humm notify_slack_error --appName PROJECT_NAME

Jira changelog webhook #

# Send data for jira webhook in format
{
  'changelog': changelog,
  'releaseVersion': releaseVersion,
}

#! Remember to set environment variables before use.
JIRA_WEBHOOK_URL = $JIRA_WEBHOOK_URL
JIRA_WEBHOOK_TOKEN = $JIRA_WEBHOOK_TOKEN 

# Eg. changelog if changelog version is in format x.y.z+y u have to provide entire number with +y value

# 6.5.12+45 [01.01.2020 15:00]

# - [fix] Fix in display wallet info in attendance row [1500]

# In changelog provided above

humm jira_changelog 6.5.12+42

humm jira_changelog $VERSION 

Check translations #

# Verify all ARB translation files in the project
humm check_translations

Check unused assets #

# Checks if all assets from /assets folder exists in pubspec.yaml then in code
humm check_unused_assets

Check strings #

# Find and display all static strings in widgets
humm check_strings

Clean up ARB files #

# Find and remove unused ARB keys
humm cleanup_arb

# Options
humm cleanup_arb --arb-dir lib/l10n         # Custom ARB directory (default: lib/l10n)
humm cleanup_arb --source-dir lib           # Custom source directory (default: lib)
humm cleanup_arb --access-pattern S.current # Translation access pattern (default: S.current)
humm cleanup_arb --verbose                  # Show detailed output
humm cleanup_arb --dry-run                  # Show what would be done without making changes

Cache Invalidation #

# Invalidate AWS CloudFront cache
humm invalidate

Requirements #

• Dart SDK >=3.0.0
• AWS CLI access (for CloudFront commands)
• Configured environment variables (for notifications and cache invalidation)

Environment Variables #

The following environment variables are required for different functionalities:

Slack Notifications #

Configure webhook or you can provide it by passing --url param in command:

SLACK_WEBHOOK=https://hooks.slack.com/services/...

Jira changelog webhook #

Configure webhook and token

JIRA_WEBHOOK_URL = $JIRA_WEBHOOK_URL
JIRA_WEBHOOK_TOKEN = $JIRA_WEBHOOK_TOKEN

AWS CloudFront Invalidation #

CLOUD_DISTRIBUTION=E1234567890ABCD

Usage in CI/CD (Codemagic example) #

workflows:
  my-workflow:
    environment:
      vars:
        # Slack webhooks for different projects
        SLACK_WEBHOOK_PROJECT1: $PROJECT1_WEBHOOK
        SLACK_WEBHOOK_PROJECT2: $PROJECT2_WEBHOOK
        # CloudFront distribution
        CLOUD_DISTRIBUTION: $CLOUDFRONT_ID
        # Jira 
        JIRA_WEBHOOK_URL: $JIRA_WEBHOOK_URL
        JIRA_WEBHOOK_TOKEN: $JIRA_WEBHOOK_TOKEN


    scripts:
      - name: Send notification
        script: |
          humm notify_slack --appName PROJECT1 --message "Build completed" --url YOUR_CUSTOM_URL
      
      - name: Invalidate cache
        script: |
          humm invalidate

      - name: Send changelog to jira
        script: |
          jira_changelog $VERSION

Example Git Flow #

Branches

main: Production branch - contains current prod version.
develop: Staging branch.
releases/<version>: Release branches, e.g., releases/1.4.x, releases/1.4.x.
# Or in cases of mono repos with multiple projects
releases/<component>/<version>: Release branches, e.g., releases/appName/1.4.x, releases/appName2/3.5.x.

How It Works

Developers should work on feature branches, which are then merged into release branches (e.g., releases/1.4.x or releases/appName/1.4.x).

If the CI/CD pipeline is configured to trigger releases(e,g. ci-cd-examples/example-ci-cd-create-version.yaml), any push or merge to a releases/x branch will automatically initiate a release process, it will:

Update the pubspec.yaml file with the new version.
Update the changelog automatically.
Create a version tag to trigger the release workflow (see an example for tag triggers in ci-cd-examples/example-tag-trigger.yaml).
Create or Update Release Branches:
Using the GitHub Actions workflow (e.g., ci-cd-examples/example-create-or-update-branch.yaml):

Once the work for a version is complete, the release branch is merged into develop.

The action detects the merged release branch and determines the next version.
If a branch for the next version does not exist (e.g., releases/1.5.x or releases/appName/1.5.x), the workflow creates the new release branch and updates the pubspec.yaml file with the next version. The new branch is then pushed to the repository.
If the next branch already exists (e.g., releases/1.5.x), the workflow creates pull requests from develop to all higher-version branches (based on pubspec.yaml from develop) (e.g., releases/1.6.x, releases/1.7.x) to propagate changes.
Manual Conflict Resolution:
Developers must manually review and resolve any conflicts in the pull requests created for higher-version branches before merging them.