feat: adding pipeline step

[mayankmahavar1mg]

---

DeputyDev generated PR summary:

---

Size XL: This PR changes include 689 lines and should take approximately 3-6 hours to review

---

The pull request (PR) adds a Publishing Guide for a GitHub Actions workflow to the repository. This guide provides detailed instructions on using the workflow to publish two packages: catalyst-core and catalyst-core-internal. Here's a summary of the key aspects:

1. Triggering and Configuration:

   • Explains how to start the workflow manually from the GitHub Actions tab.
   • Details options for selecting the branch, package type, version type, and other configurations like dry run and custom versioning.

2. Workflow Steps:

   • Describes the steps for publishing both internal and main packages.
   • Includes branch checkout, package.json updates, route changes, building, publishing, tagging, and restoration processes.

3. Key Features:

   • Allows branch selection, version validation, dry run for testing, and complete repository restoration after execution.
   • Creates detailed git tags and provides progress tracking.

4. Security and Setup:

   • Requires an NPM_TOKEN secret for authentication during publishing.

5. Usage Scenarios:

   • Provides example scenarios to illustrate how different configurations affect the publishing process.

6. Troubleshooting and Branch Strategy:

   • Lists common issues and solutions, plus recommended branch usage and tagging information.

The guide overall helps users to correctly and efficiently use the publishing workflow integrated into the GitHub Actions of the repository.

---

DeputyDev generated PR summary until 5dc98f9

[deputydev-agent]

DeputyDev has started reviewing your pull request.

[deputydev-agent]

CODE_MAINTAINABILTIY: The publishing process creates backups using simple file renaming, which is fragile and doesn't handle errors or interruptions well. If the workflow is interrupted mid-execution, it could leave the repository in an inconsistent state.
The current backup mechanism is fragile and doesn't properly handle failure scenarios. A more robust approach would be to store backups in a separate directory with timestamping and provide proper error handling. This would significantly improve the robustness of the workflow, especially when dealing with unexpected interruptions during execution.

# Create backup directory
BACKUP_DIR=".publish-backup-$(date +%s)"
mkdir -p "$BACKUP_DIR"

# Backup files with error handling
cp package.json "$BACKUP_DIR/" || { echo "Backup failed"; exit 1; }
if [ -f package-lock.json ]; then
  cp package-lock.json "$BACKUP_DIR/" || { echo "Backup failed"; exit 1; }
fi

# Store file list in backup directory
find . -type f \( -name "*.js" -o -name "*.jsx" -o -name "*.ts" -o -name "*.tsx" -o -name "*.json" \) \
  -not -path "./node_modules/*" \
  -not -path "./.git/*" \
  -not -path "./dist/*" \
  -not -path "./$BACKUP_DIR/*" \
  -exec grep -l "catalyst-core" {} + > "$BACKUP_DIR/modified-files.txt" 2>/dev/null || true

# Restoration function in a separate file that can be called on failure
cat > restore-backup.sh << 'EOF'
#!/bin/bash
BACKUP_DIR="$1"
if [ -d "$BACKUP_DIR" ]; then
  echo "Restoring from backup: $BACKUP_DIR"
  # Restore package files
  cp "$BACKUP_DIR/package.json" ./ 2>/dev/null || true
  cp "$BACKUP_DIR/package-lock.json" ./ 2>/dev/null || true
  # Reset changed files
  git checkout HEAD -- . 2>/dev/null || true
  echo "Restoration complete"
fi
EOF
chmod +x restore-backup.sh

[deputydev-agent]

CODE_MAINTAINABILTIY: The workflow contains commented-out code for the actual publishing step, with a 'TESTING' message in its place. While this is likely intentional during development, it should be properly documented or removed before final implementation.
The workflow contains commented-out code along with a temporary testing implementation, which can cause confusion and lead to accidental use of the testing mode in production. Either the actual publishing code should be uncommented and the testing code removed, or the testing code should be properly documented to make it clear that this is not the final implementation.

# Choose one of these two implementations and remove the other:  

# Option 1: Implement the actual publishing step
- name: Publish to npm
  if: github.event.inputs.dry_run != 'true'
  run: |
    echo "📤 Publishing to npm..."
    npm publish --access public
    echo "✅ Published successfully to npm"
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
    
# Option 2: Keep the testing mode but add proper documentation
- name: Publish to npm (Testing Mode)
  if: github.event.inputs.dry_run != 'true'
  run: |
    echo "🧪 TESTING MODE - Simulating npm publish..."
    echo "📤 Would publish to npm with command: npm publish --access public"
    echo "📦 Package: ${{ steps.next_version.outputs.package_name }}"
    echo "🔕 Version: ${{ steps.next_version.outputs.next_version }}"
    echo "✅ Simulated publish completed successfully"
    echo ""
    echo "⚠️ NOTE: This is currently in testing mode. When ready for production:"
    echo "1. Uncomment the actual publishing step in the workflow file"
    echo "2. Remove this testing step"
    echo "3. Ensure NPM_TOKEN secret is configured"

[deputydev-agent]

ERROR: The find command in the backup creation step uses + which can cause command line length limitations when there are too many matching files. This may lead to command failure without proper error handling when the file list exceeds the shell's maximum command length.
When using + with exec in find commands, all matched filenames are appended to a single command execution. If there are hundreds or thousands of files matching the pattern, this can exceed the shell's maximum command line length limit, causing the command to fail. Using \; instead executes the command separately for each file, avoiding this limitation.

# Create a list of files containing catalyst-core references for restoration
find . -type f \( -name "*.js" -o -name "*.jsx" -o -name "*.ts" -o -name "*.tsx" -o -name "*.json" \) \
  -not -path "./node_modules/*" \
  -not -path "./.git/*" \
  -not -path "./dist/*" \
  -exec grep -l "catalyst-core" {} \; > catalyst-core-files.txt 2>/dev/null || true

[deputydev-agent]

ERROR: The actual publishing step is commented out while a simulation step is active, but the guide indicates that the workflow will publish packages. This mismatch between documentation and implementation will confuse users.
The guide states that the workflow publishes packages, but the actual publishing step is commented out in favor of a simulation step. When users follow the guide expecting real publishing to occur, they will only get simulated results. Either the code should be uncommented or the guide should clearly state that publishing is currently in simulation mode only.

# Ensure commented publishing code is properly aligned with the simulation code
- name: Publish to npm
  if: github.event.inputs.dry_run != 'true'
  run: |
    echo "\ud83d\udce4 Publishing to npm..."
    npm publish --access public
    echo "\u2705 Published successfully to npm"
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

# Keep this for testing until ready
# - name: TESTING - Simulate Publish
#   if: github.event.inputs.dry_run != 'true'
#   run: |
#     echo "\ud83e\uddea TESTING MODE - Simulating npm publish..."
#     echo "\ud83d\udce4 Would publish to npm with command: npm publish --access public"
#     echo "\ud83d\udce6 Package: ${{ steps.next_version.outputs.package_name }}"
#     echo "\ud83c\udd95 Version: ${{ steps.next_version.outputs.next_version }}"
#     echo "\u2705 Simulated publish completed successfully"

[deputydev-agent]

DeputyDev has completed a review of your pull request for commit 5dc98f9.

[mayankmahavar1mg]

/test

[mayankmahavar1mg]

/test