# Gemfile for common development/testing tools
# We recommend isolating test-specific gems in a :development, :test group.
# For example, RSpec and FactoryBot are essential for robust testing.

# Gemfile

group :development, :test do
  gem 'rspec-rails', '~> 6.0'
  gem 'factory_bot_rails', '~> 6.2'
  gem 'faker', '~> 2.20' # For generating realistic test data
  gem 'capybara', '~> 3.39' # For feature testing
  gem 'selenium-webdriver', '~> 4.10' # For browser automation with Capybara
  gem 'webdrivers', '~> 5.2' # Automatically download webdriver binaries
  gem 'simplecov', require: false # Code coverage reports
end

# Rake task for basic sprint overview setup (conceptual)
# You might integrate this with your project management tool's API

# lib/tasks/sprint_tasks.rake

namespace :sprint do
  desc "Initializes a new sprint and sets up basic reporting."
  task :init, [:sprint_number, :start_date, :end_date] do |t, args|
    unless args[:sprint_number] && args[:start_date] && args[:end_date]
      puts "Usage: rake sprint:init[sprint_number,start_date,end_date]"
      exit 1
    end

    puts "Activating Sprint #{args[:sprint_number]} from #{args[:start_date]} to #{args[:end_date]}"
    # In a real scenario, this would interact with Jira/Trello/Asana APIs
    # or update an internal sprint tracking mechanism.
    # Example: Create a new sprint board, set sprint dates, notify team.
    puts "Placeholder for API calls to create sprint and generate initial reports."
    puts "Reporting setup complete for Sprint #{args[:sprint_number]}."
  end

  desc "Generates a daily sprint progress report."
  task :daily_report do
    puts "Decoding daily sprint progress..."
    # This would pull data from your issue tracker (e.g., tickets completed, blockers).
    # Example: Query Jira for all active tickets in the current sprint.
    puts "Tickets completed: X, Tickets remaining: Y, Blockers: Z."
    puts "Report generated at #{Time.now}."
  end
end

# Example .rubocop.yml for Rails-centric Ruby teams
# We recommend a strict but reasonable set of cops to enforce consistency and quality.

# .rubocop.yml

require: # Load community extensions if desired
  - rubocop-rails
  - rubocop-performance
  - rubocop-rspec

AllCops:
  TargetRubyVersion: 3.2 # Adjust to your project's Ruby version
  NewCops: enable # Always enable new cops for future compatibility
  Exclude:
    - 'bin/**/*'
    - 'db/schema.rb'
    - 'vendor/**/*'
    - 'node_modules/**/*'
    - 'config/environments/**/*'
    - 'config/initializers/**/*'
    - 'lib/tasks/**/*' # Exclude Rake tasks if they don't follow standard Ruby style

# Core Ruby Style guidelines
Style/FrozenStringLiteralComment:
  Enabled: true # Promote immutability
Style/Documentation:
  Enabled: false # Often too verbose for internal app code
Style/StringLiterals:
  EnforcedStyle: single_quotes
Style/ClassAndModuleChildren:
  EnforcedStyle: compact # e.g., class MyClass; class NestedClass; end; end

# Rails-specific guidelines
Rails/CreateTableWithTimestamps:
  Enabled: true # Ensure all tables have timestamps
Rails/HasAndBelongsToMany:
  Enabled: false # Prefer has_many :through for clearer relationships
Rails/HttpStatus:
  EnforcedStyle: symbolic # Use symbols like :ok instead of 200

# Performance optimizations
Performance/FlatMapWithIndex:
  Enabled: true
Performance/Sum:
  Enabled: true

# RSpec-specific guidelines
RSpec/DescribeClass:
  Enabled: true
RSpec/ExampleLength:
  Max: 10 # Keep examples concise

# Example Dangerfile for automated code review checks
# We leverage Danger to enforce project-specific rules directly in the PR flow.

# Dangerfile

# Ensure the PR description is not empty
if github.pr_body.length < 10
  warn("Please provide a more descriptive pull request body.")
end

# Check if the title starts with a conventional commit prefix (e.g., 'feat:', 'fix:')
unless github.pr_title.match?(/^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert):/)
  fail("PR title must follow Conventional Commits spec (e.g., 'feat: Add new feature').")
end

# Mandate minimum number of reviewers
if github.requested_reviewers.count < 2
  warn("Consider adding more reviewers for critical changes.")
end

# Detect if new migrations were added without a corresponding test or note
new_migrations = git.modified_files.select { |f| f.include?("db/migrate") }
if new_migrations.any?
  message("New database migrations detected. Ensure they are reversible and tested.")
end

# Check for uncommitted debuggers (e.g., 'binding.pry')
modified_ruby_files = git.modified_files.select { |f| f.end_with?('.rb') }
modified_ruby_files.each do |file|
  file_content = File.read(file)
  if file_content.include?('binding.pry') || file_content.include?('byebug')
    fail("Found debugging statements (binding.pry/byebug) in #{file}. Please remove before merging.")
  end
end

# Ensure dependencies are updated (Gemfile.lock change)
if git.modified_files.include?('Gemfile.lock')
  message("Gemfile.lock modified. Remember to run `bundle install` and commit if necessary.")
end

# Run RuboCop automatically on changed Ruby files
puts "Running RuboCop on changed Ruby files..."
sh("bundle exec rubocop --format github --force-exclusion")

# No direct Ruby code for stand-ups/retrospectives, but conceptual setup for tracking.
# This illustrates integrating with a project management tool using a simple Rake task.

# lib/tasks/meeting_tasks.rake

namespace :meeting do
  desc "Logs a daily stand-up entry for reporting purposes."
  task :log_standup, [:team_member, :yesterday, :today, :blockers] do |t, args|
    unless args[:team_member] && args[:yesterday] && args[:today]
      puts "Usage: rake meeting:log_standup[team_member,yesterday,today,blockers]"
      exit 1
    end

    puts "Logging stand-up for #{args[:team_member]}..."
    puts "  Yesterday: #{args[:yesterday]}"
    puts "  Today: #{args[:today]}"
    puts "  Blockers: #{args[:blockers] || 'None'}"
    # In a real system, this would push data to a central reporting database
    # or a dedicated stand-up logging tool.
    puts "Stand-up data recorded."
  end

  desc "Prepares the retrospective board (conceptual)."
  task :prepare_retro do
    puts "Activating retrospective preparation..."
    puts "  1. Reviewing Sprint Metrics (velocity, burndown)."
    puts "  2. Setting up collaborative board (e.g., Miro, Trello, Confluence)."
    puts "  3. Notifying team for input on What Went Well, What Could Be Improved, Action Items."
    puts "Retrospective board ready for input."
  end
end

# Example GitHub Actions workflow for a Rails application
# This workflow automates testing and deployment (to a staging environment).

# .github/workflows/ci_cd.yml

name: Ruby on Rails CI/CD

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    branches:
      - main
      - develop

jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: ruby:3.2.2 # Specify your Ruby version
      services:
        postgres:
          image: postgres:13
          env:
            POSTGRES_DB: rails_test
            POSTGRES_USER: runner
            POSTGRES_PASSWORD: ''
          ports:
            - 5432:5432
          options: >- # Health check for PostgreSQL
            --health-cmd pg_isready
            --health-interval 10s
            --health-timeout 5s
            --health-retries 5
    env:
      RAILS_ENV: test
      DATABASE_URL: 'postgresql://runner:@localhost:5432/rails_test'

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Install dependencies
      run: |
        gem install bundler -v '~> 2.4'
        bundle install --jobs 4 --retry 3 # Optimize bundle install

    - name: Set up database
      run: |
        bundle exec rails db:create
        bundle exec rails db:migrate

    - name: Run RSpec tests
      run: bundle exec rspec

    - name: Run RuboCop
      run: bundle exec rubocop --parallel

  deploy_staging:
    needs: build # This job depends on the 'build' job completing successfully
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' # Only deploy main branch to staging
    environment: staging # Designate a GitHub Environments for secrets management
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Deploy to Staging
      env:
        SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }} # Store SSH key in GitHub Secrets
        DEPLOY_HOST: ${{ secrets.STAGING_HOST }}
        DEPLOY_USER: ${{ secrets.STAGING_USER }}
      run: |
        mkdir -p ~/.ssh
        echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
        chmod 600 ~/.ssh/id_rsa
        ssh-keyscan -H $DEPLOY_HOST >> ~/.ssh/known_hosts
        # Example Capistrano deployment command (or similar for other tools like Kamal, Mina)
        ssh $DEPLOY_USER@$DEPLOY_HOST "cd /var/www/your_app && bundle exec cap staging deploy"
        echo "Deployment to staging initiated."