Migration & DevOps Automation

Move Files Exceeding Path Length Limit (Version Control Migration)

Problem

GitHub and Windows impose a 260-character limit on full file paths. During VCS migrations, files with deeply nested directory structures or long filenames exceed this limit, causing push failures and blocking repository migration. Without automated path length detection, migration projects stall on edge cases discovered late in the process.

Solution

PowerShell script that recursively scans the repository, identifies files exceeding the 260-character path limit, and moves them to a designated folder while preserving their original directory structure. This isolates problematic files for manual review without blocking the main migration workflow.

Implementation

param(
    [string]$SourcePath = ".",
    [string]$DestPath = ".\LongPaths",
    [int]$MaxPathLength = 260
)

$sourceFullPath = (Resolve-Path $SourcePath).Path

Get-ChildItem -Path $SourcePath -Recurse -File | Where-Object {
    $_.FullName.Length -gt $MaxPathLength
} | ForEach-Object {
    $file = $_
    $relativePath = $file.FullName.Substring($sourceFullPath.Length + 1)
    $destFile = Join-Path $DestPath $relativePath
    $destDir = Split-Path $destFile -Parent

    if (-not (Test-Path $destDir)) {
        New-Item -ItemType Directory -Path $destDir -Force | Out-Null
    }

    Write-Host "Moving: $relativePath (Length: $($file.FullName.Length))"
    Move-Item -Path $file.FullName -Destination $destFile -Force
}

Remove Archive Extensions from Filenames

Problem

Legacy version control systems sometimes append archive suffixes to file revisions. When migrating to Git, these archive suffixes persist in filenames, creating confusion about which files are current. Manually renaming hundreds or thousands of files is impractical and error-prone.

Solution

PowerShell script that recursively identifies all files with archive suffixes and removes these suffixes while preserving the rest of the filename and extension. Handles collision detection and supports dry-run mode.

Implementation

param(
    [string]$Path = ".",
    [string]$Suffix = "-arc",
    [switch]$WhatIf
)

Get-ChildItem -Path $Path -Recurse -File | Where-Object {
    $_.Name -match $Suffix
} | ForEach-Object {
    $file = $_
    $newName = $file.Name -replace $Suffix, ''
    $newPath = Join-Path $file.DirectoryName $newName

    if (Test-Path $newPath) {
        Write-Warning "Collision: $newPath already exists. Skipping $($file.Name)"
    } else {
        Write-Host "Renaming: $($file.Name) -> $newName"
        if (-not $WhatIf) {
            Rename-Item -Path $file.FullName -NewName $newName
        }
    }
}

# Usage:
# .\Remove-ArchiveSuffix.ps1 -WhatIf   # preview
# .\Remove-ArchiveSuffix.ps1            # execute

Move Large Files for Git LFS Processing

Problem

GitHub repositories have a 100MB file size limit. Files exceeding this limit cause push failures and block repository migration. Identifying which files need LFS treatment across thousands of repository files is time-intensive.

Solution

PowerShell script that scans the repository recursively, identifies files exceeding 100MB, and moves them to a designated folder for Git LFS configuration or alternate storage strategies.

Implementation

param(
    [string]$SourcePath = ".",
    [string]$DestPath = ".\LargeFiles",
    [int]$MaxSizeMB = 100
)

$maxSizeBytes = $MaxSizeMB * 1MB
$sourceFullPath = (Resolve-Path $SourcePath).Path

Get-ChildItem -Path $SourcePath -Recurse -File | Where-Object {
    $_.Length -gt $maxSizeBytes
} | ForEach-Object {
    $file = $_
    $relativePath = $file.FullName.Substring($sourceFullPath.Length + 1)
    $destFile = Join-Path $DestPath $relativePath
    $destDir = Split-Path $destFile -Parent

    if (-not (Test-Path $destDir)) {
        New-Item -ItemType Directory -Path $destDir -Force | Out-Null
    }

    $sizeMB = [math]::Round($file.Length / 1MB, 2)
    Write-Host "Moving: $relativePath (Size: $sizeMB MB)"
    Move-Item -Path $file.FullName -Destination $destFile -Force
}

Post-Migration Git LFS Setup:

git lfs install
git lfs track "*.iso"
git lfs track "*.mp4"
git lfs track "*.zip"
git add .gitattributes
git commit -m "Add large files via Git LFS"

GitHub Enterprise Pull Request Template Configuration

Problem

Development teams working with mixed technology stacks require different pull request templates for different types of changes. Standard code changes need basic testing checklists while specialized application changes require validation covering page modifications, database objects, SQL security, session state, and deployment procedures.

Solution

Implement a combined pull request template that includes conditional sections for both standard code changes and specialized application testing. Developers delete the section they're not using. This works universally across GitHub Enterprise versions without requiring special directory structures or dropdown functionality.

Implementation

File location: .github/pull_request_template.md

<!--
INSTRUCTIONS: Delete the section you're NOT using.
For standard code changes, delete "Application Testing" section.
For application changes, delete "Standard Pull Request" section.
-->

---

# STANDARD PULL REQUEST
<!-- Delete this section if this is an application change -->

## Description

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed

## Checklist
- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] No new warnings generated

---

# APPLICATION TESTING
<!-- Delete this section if this is a standard code change -->

## Application Details
**Application ID:**
**Target Environment:**

## Type of Change
- [ ] New page/region
- [ ] SQL/PLSQL code update
- [ ] Database object change
- [ ] Authorization/authentication modification

## SQL/PLSQL Code Review
- [ ] Bind variables used (no SQL injection risk)
- [ ] Proper exception handling
- [ ] No hard-coded values

## Deployment Notes
- [ ] Run pre-deployment scripts
- [ ] Import application
- [ ] Run post-deployment scripts
- [ ] Clear cache

Why Combined Template: No special directory structure required, compatible with all GHE versions, works with GitHub Desktop. If dropdown selector doesn't appear despite correct PULL_REQUEST_TEMPLATE/ directory structure, use combined template instead — single root-level file takes precedence.