Skip to content

Create build.yml#866

Merged
guibranco merged 20 commits into
mainfrom
guibranco-patch-1
May 19, 2026
Merged

Create build.yml#866
guibranco merged 20 commits into
mainfrom
guibranco-patch-1

Conversation

@guibranco

@guibranco guibranco commented Mar 27, 2026

Copy link
Copy Markdown
Owner

User description

📑 Description

Create build.yml

✅ Checks

  • My pull request adheres to the code style of this project
  • My code requires changes to the documentation
  • I have updated the documentation as required
  • All the tests have passed

☢️ Does this introduce a breaking change?

  • Yes
  • No

Summary by Sourcery

Add a GitHub Actions workflow to build, test, and analyze the .NET solution on pushes and pull requests.

CI:

  • Introduce a CI workflow that runs on non-main pushes and all pull requests, with concurrency control to cancel in-progress runs per ref.
  • Configure the workflow to build the .NET solution, run tests with coverage, and upload test result artifacts.
  • Integrate SonarCloud analysis, Codecov, and Codacy coverage reporting for internal branches and same-repo pull requests only.

Summary by CodeRabbit

  • Chores
    • Added an automated CI pipeline that runs builds and tests, collects coverage, and uploads results to coverage and code-quality services to maintain reliability and quality.
    • Added automated code analysis and reporting for pull requests and manual runs to surface issues early and ensure consistent quality checks.

Review Change Stack


Description

  • Introduced a comprehensive CI workflow that builds, tests, and analyzes the .NET solution.
  • The workflow runs on pushes to non-main branches and all pull requests, with concurrency control.
  • Integrated tools for code quality analysis (SonarCloud, Codecov, Codacy) for internal branches and same-repo pull requests.
  • Added steps for setting up a CouchDB service and managing versioning with GitVersion.

Changes walkthrough 📝

Relevant files
Enhancement
build.yml
Implement CI Workflow for .NET Solution with Quality Checks

.github/workflows/build.yml

  • Added a CI workflow for building, testing, and analyzing a .NET
    solution.
  • Configured concurrency control for GitHub Actions.
  • Integrated SonarCloud, Codecov, and Codacy for code quality reporting.
  • Set up a CouchDB service for testing.
  • +196/-0 

    💡 Penify usage:
    Comment /help on the PR to get a list of all available Penify tools and their descriptions

    @sourcery-ai

    sourcery-ai Bot commented Mar 27, 2026

    Copy link
    Copy Markdown

    Reviewer's Guide

    Adds a GitHub Actions CI workflow that builds, tests, performs code coverage, and integrates with SonarCloud, Codecov, and Codacy for a .NET solution using CouchDB as a service container.

    Flow diagram for build · test · coverage GitHub Actions job

    flowchart LR
      A["push_or_pull_request_trigger"] --> B["start_build_test_coverage_job"]
      B --> C["start_CouchDB_service_container"]
      C --> D["checkout_repository"]
      D --> E["setup_DotNet_10"]
      E --> F["setup_Java_21"]
      F --> G["install_GitVersion_tool"]
      G --> H["determine_semantic_version_with_GitVersion"]
      H --> I["patch_props_files_with_computed_version"]
      I --> J["resolve_solution_name"]
      J --> K["install_dotnet_sonarscanner_global_tool"]
      K --> L["dotnet_restore"]
      L --> M["resolve_Sonar_context_flags_internal_vs_fork"]
    
      M --> N{"is_internal_branch_or_PR"}
    
      N -->|yes| O["begin_SonarCloud_scan"]
      N -->|no| P["skip_SonarCloud_begin"]
    
      O --> Q["dotnet_build_solution"]
      P --> Q
    
      Q --> R["run_dotnet_test_for_each_project_with_coverage"]
      R --> S["upload_JUnit_test_results_artifact"]
    
      S --> T{"is_internal_branch_or_PR"}
    
      T -->|yes| U["upload_coverage_to_Codecov"]
      T -->|yes| V["report_coverage_to_Codacy"]
      T -->|no| W["skip_external_coverage_reporting"]
    
      U --> X["end_SonarCloud_scan_if_started"]
      V --> X
      W --> X
    
      X --> Y["job_complete"]
    
    Loading

    File-Level Changes

    Change Details Files
    Introduce a GitHub Actions CI workflow for .NET with CouchDB service and concurrency control.
    • Configure workflow triggers for push (excluding main) and pull_request events
    • Set global .NET environment variables and define a single ubuntu-latest job
    • Add CouchDB 3.3.3 service container with health checks for integration tests
    • Configure workflow-level concurrency to cancel in-progress runs for the same ref
    .github/workflows/build.yml
    Set up .NET, Java, and GitVersion toolchain and propagate computed version into project props.
    • Install .NET 10 and Java 21 via setup actions
    • Install and run GitVersion to compute semantic version information
    • Patch all .props files with the computed semantic version across Version, PackageVersion, AssemblyVersion, FileVersion, and InformationalVersion elements
    .github/workflows/build.yml
    Automate solution discovery, restore, build, and test execution with coverage for all test projects.
    • Dynamically resolve the solution name by scanning for .sln files
    • Install dotnet-sonarscanner as a global tool and restore NuGet packages
    • Build the discovered solution with minimal verbosity and no restore
    • Iterate over all test csproj files under Tests to run dotnet test with coverage collection in multiple formats and JUnit logging
    • Upload test result XML files as workflow artifacts
    .github/workflows/build.yml
    Conditionally integrate SonarCloud, Codecov, and Codacy coverage reporting, handling forked PRs securely.
    • Detect whether the workflow run originates from a forked pull request and expose a boolean flag
    • Derive SonarCloud project key and organization from GitHub repository metadata
    • Invoke dotnet sonarscanner begin/end only for non-fork contexts, configuring exclusions, coverage paths, and PR/branch metadata
    • Send coverage reports to Codecov and Codacy using repository secrets, gated on non-fork context and fixed coverage file paths
    .github/workflows/build.yml

    Tips and commands

    Interacting with Sourcery

    • Trigger a new review: Comment @sourcery-ai review on the pull request.
    • Continue discussions: Reply directly to Sourcery's review comments.
    • Generate a GitHub issue from a review comment: Ask Sourcery to create an
      issue from a review comment by replying to it. You can also reply to a
      review comment with @sourcery-ai issue to create an issue from it.
    • Generate a pull request title: Write @sourcery-ai anywhere in the pull
      request title to generate a title at any time. You can also comment
      @sourcery-ai title on the pull request to (re-)generate the title at any time.
    • Generate a pull request summary: Write @sourcery-ai summary anywhere in
      the pull request body to generate a PR summary at any time exactly where you
      want it. You can also comment @sourcery-ai summary on the pull request to
      (re-)generate the summary at any time.
    • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
      request to (re-)generate the reviewer's guide at any time.
    • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
      pull request to resolve all Sourcery comments. Useful if you've already
      addressed all the comments and don't want to see them anymore.
    • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
      request to dismiss all existing Sourcery reviews. Especially useful if you
      want to start fresh with a new review - don't forget to comment
      @sourcery-ai review to trigger a new review!

    Customizing Your Experience

    Access your dashboard to:

    • Enable or disable review features such as the Sourcery-generated pull request
      summary, the reviewer's guide, and others.
    • Change the review language.
    • Add, remove or edit custom review instructions.
    • Adjust other review settings.

    Getting Help

    @guibranco
    guibranco enabled auto-merge (squash) March 27, 2026 16:08
    @gstraccini gstraccini Bot added the ☑️ auto-merge Automatic merging of pull requests (gstraccini-bot) label Mar 27, 2026
    @github-actions github-actions Bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Mar 27, 2026
    @coderabbitai

    coderabbitai Bot commented Mar 27, 2026

    Copy link
    Copy Markdown
    Contributor

    Note

    Reviews paused

    It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

    Use the following commands to manage reviews:

    • @coderabbitai resume to resume automatic reviews.
    • @coderabbitai review to trigger a single review.

    Use the checkboxes below for quick actions:

    • ▶️ Resume reviews
    • 🔍 Trigger review

    Walkthrough

    Adds a new GitHub Actions workflow .github/workflows/build.yml that triggers on push/PR/dispatch, provisions CouchDB, checks out and sets up Java 17/.NET 10.x, restores/builds/tests with coverage, runs SonarCloud analysis, uploads to Codecov, and conditionally reports coverage to DeepSource.

    Changes

    CI Workflow

    Layer / File(s) Summary
    Workflow triggers & concurrency
    .github/workflows/build.yml
    Workflow triggers on push to main, PR events, and workflow_dispatch; sets per-ref concurrency to cancel in-progress runs.
    CouchDB service container
    .github/workflows/build.yml
    Adds CouchDB 3.3.3 service with admin creds, exposes port 5984, and health check at /_up.
    Checkout, runtimes and tooling setup
    .github/workflows/build.yml
    Checks out repo using PR head SHA when applicable; sets up Java 17 (Temurin) and .NET SDK 10.0.x; installs dotnet-sonarscanner and DeepSource CLI.
    NuGet cache and restore
    .github/workflows/build.yml
    Caches NuGet packages (key includes OS + hashes of **/*.csproj, **/global.json, **/packages.lock.json) and runs dotnet restore.
    Sonar begin, build, test, sonar end
    .github/workflows/build.yml
    Begins SonarCloud analysis (dotnet sonarscanner begin), builds in Release (--no-restore), runs dotnet test with Coverlet producing opencover and cobertura, then dotnet sonarscanner end.
    Coverage upload and DeepSource report
    .github/workflows/build.yml
    Uploads coverage to Codecov (codecov/codecov-action@v6) with CODECOV_TOKEN; conditionally runs ./bin/deepsource report against Tests/CrispyWaffle.Tests/coverage.net9.0.cobertura.xml when in-repo PR or workflow_dispatch using DEEPSOURCE_DSN.

    Sequence Diagram(s)

    sequenceDiagram
      actor GH as GitHub
      participant Runner as "Actions Runner"
      participant Repo as "Repository (checkout)"
      participant CouchDB as "CouchDB 3.3.3"
      participant Runtimes as "Java 17 / .NET 10.x"
      participant Tools as "SonarScanner / DeepSource CLI"
      participant Build as "dotnet restore/build/test"
      participant Sonar as SonarCloud
      participant Codecov as Codecov
      participant DeepSource as DeepSource
    
      GH->>Runner: Trigger (push / pull_request / workflow_dispatch)
      Runner->>Repo: checkout (PR head SHA when applicable)
      Runner->>CouchDB: start service (port 5984, healthcheck /_up)
      Runner->>Runtimes: setup Java 17 and .NET 10.x
      Runner->>Tools: install dotnet-sonarscanner and DeepSource CLI
      Runner->>Build: dotnet restore -> dotnet build --no-restore -> dotnet test (collect coverage opencover,cobertura)
      Build-->>Runner: coverage reports
      Runner->>Sonar: dotnet sonarscanner begin ... end (analysis upload)
      Runner->>Codecov: upload coverage (CODECOV_TOKEN)
      Runner->>DeepSource: run ./bin/deepsource report (conditional on in-repo PR or dispatch)
      CouchDB-->>Build: respond to test requests (health OK)
    
    Loading

    Estimated code review effort

    🎯 3 (Moderate) | ⏱️ ~20 minutes

    Poem

    🐰 I hopped through YAML lines today,

    CouchDB warmed, the runners play,
    Runtimes set and scanners spun,
    Coverage gathered, uploads done,
    A cheerful rabbit says: CI hooray!

    🚥 Pre-merge checks | ✅ 4 | ❌ 1

    ❌ Failed checks (1 inconclusive)

    Check name Status Explanation Resolution
    Title check ❓ Inconclusive The title 'Create build.yml' is vague and generic, using a non-descriptive verb-object format that lacks context about the workflow's purpose or the specific CI/CD functionality being introduced. Improve the title to be more descriptive of the workflow's primary purpose, such as 'Add GitHub Actions CI workflow with SonarCloud and code coverage analysis' or 'Set up automated build and test workflow with code quality integration'.
    ✅ Passed checks (4 passed)
    Check name Status Explanation
    Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
    Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
    Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
    Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

    ✏️ Tip: You can configure your own custom pre-merge checks in the settings.

    ✨ Finishing Touches
    🧪 Generate unit tests (beta)
    • Create PR with unit tests
    • Commit unit tests in branch guibranco-patch-1

    Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

    ❤️ Share

    Comment @coderabbitai help to get the list of available commands and usage tips.

    @sourcery-ai sourcery-ai Bot left a comment

    Copy link
    Copy Markdown

    Choose a reason for hiding this comment

    The reason will be displayed to describe this comment to others. Learn more.

    Hey - I've found 1 issue, and left some high level feedback:

    • The coverage file paths are hard-coded to coverage.net9.0.opencover.xml in both SonarCloud and Codecov/Codacy steps, but the test command never sets CoverletOutput or the target framework in the path, so these uploads will likely fail—either align the test output naming to that path or make the reporting steps discover the generated files dynamically.
    • The CouchDB admin credentials are embedded directly in the workflow file; consider moving COUCHDB_USER and especially COUCHDB_PASSWORD to GitHub Action secrets or at least environment variables at the repository level to avoid hard-coding credentials in version control.
    Prompt for AI Agents
    Please address the comments from this code review:
    
    ## Overall Comments
    - The coverage file paths are hard-coded to `coverage.net9.0.opencover.xml` in both SonarCloud and Codecov/Codacy steps, but the test command never sets `CoverletOutput` or the target framework in the path, so these uploads will likely fail—either align the test output naming to that path or make the reporting steps discover the generated files dynamically.
    - The CouchDB admin credentials are embedded directly in the workflow file; consider moving `COUCHDB_USER` and especially `COUCHDB_PASSWORD` to GitHub Action secrets or at least environment variables at the repository level to avoid hard-coding credentials in version control.
    
    ## Individual Comments
    
    ### Comment 1
    <location path=".github/workflows/build.yml" line_range="28" />
    <code_context>
    +        image: couchdb:3.3.3
    +        env:
    +          COUCHDB_USER: Admin
    +          COUCHDB_PASSWORD: myP@ssw0rd
    +        ports:
    +          - 5984:5984
    </code_context>
    <issue_to_address>
    **🚨 issue (security):** Avoid committing a hard-coded database password, even for a test-only service container.
    
    Even for CI-only containers, committing a real-looking password is poor security hygiene and can normalize the pattern elsewhere. Please switch to an obviously dummy value (e.g. `test-password`) and/or source it from a non-sensitive repo variable so no secrets appear directly in the workflow file.
    </issue_to_address>

    Sourcery is free for open source - if you like our reviews please consider sharing them ✨
    Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

    Comment thread .github/workflows/build.yml

    @coderabbitai coderabbitai Bot left a comment

    Copy link
    Copy Markdown
    Contributor

    Choose a reason for hiding this comment

    The reason will be displayed to describe this comment to others. Learn more.

    Actionable comments posted: 1

    🧹 Nitpick comments (3)
    .github/workflows/build.yml (3)

    66-76: Note: FileVersion and InformationalVersion elements don't exist in Directory.Build.props.

    The sed substitution only replaces existing elements. Since Directory.Build.props lacks <FileVersion> and <InformationalVersion> elements, those patterns will be no-ops. This is likely fine since MSBuild can derive these from <Version>, but if explicit values are needed, you'll need to add them to the props file or modify the script to insert missing elements.

    🤖 Prompt for AI Agents
    Verify each finding against the current code and only fix it if needed.
    
    In @.github/workflows/build.yml around lines 66 - 76, The workflow patches
    .props using VERSION but the sed commands only replace existing tags so
    <FileVersion> and <InformationalVersion> in Directory.Build.props remain absent;
    update the script to ensure those elements exist or are inserted when missing:
    after computing VERSION (VERSION="${{ steps.gitversion.outputs.semVer }}")
    adjust the find|xargs|sed pipeline (the current sed -e replacements) to either
    (a) append missing <FileVersion>$VERSION</FileVersion> and
    <InformationalVersion>$VERSION</InformationalVersion> into files that lack them
    or (b) change the logic to generate a minimal props fragment with all four tags
    and write/merge it into Directory.Build.props, referencing the tags <Version>,
    <PackageVersion>, <AssemblyVersion>, <FileVersion>, and <InformationalVersion>
    so explicit values are present when required.
    

    179-189: Consider pinning Codacy reporter version for reproducibility and security.

    Downloading latest from GitHub releases on every run introduces supply chain risk and can cause unexpected breakages. Consider pinning to a specific version.

    🔒 Proposed fix to pin version
           - name: Report coverage → Codacy
             if: steps.ctx.outputs.is_fork == 'false'
             run: |
               SLN="${{ steps.solution.outputs.name }}"
    +          CODACY_VERSION="13.13.7"  # Pin to specific version
               curl -fsSL \
    -            https://github.com/codacy/codacy-coverage-reporter/releases/latest/download/codacy-coverage-reporter-assembly.jar \
    +            "https://github.com/codacy/codacy-coverage-reporter/releases/download/${CODACY_VERSION}/codacy-coverage-reporter-assembly.jar" \
                 -o codacy-reporter.jar
               java -jar codacy-reporter.jar report \
                 -l CSharp \
                 -t "${{ secrets.CODACY_PROJECT_TOKEN }}" \
                 -r "Tests/${SLN}.Tests/coverage.net9.0.opencover.xml"
    🤖 Prompt for AI Agents
    Verify each finding against the current code and only fix it if needed.
    
    In @.github/workflows/build.yml around lines 179 - 189, The workflow currently
    downloads the Codacy reporter using the `latest` release URL (in the "Report
    coverage → Codacy" step), which is brittle; change the download URL to a pinned
    release (replace the
    `.../releases/latest/.../codacy-coverage-reporter-assembly.jar` URL with a
    specific tag or versioned asset) and update any references to
    `codacy-reporter.jar` accordingly (you can add a variable like REPORTER_VERSION
    and use it in the curl URL and file name) so the `java -jar codacy-reporter.jar
    report` invocation uses a reproducible, versioned reporter.
    

    78-84: Add error handling for missing solution file.

    If no .sln file is found, the script silently continues with an empty SLN variable, which will cause confusing failures downstream (e.g., building ".sln").

    🛠️ Proposed fix to add validation
           - name: Resolve solution name
             id: solution
             run: |
    -          SLN=$(find . -maxdepth 2 -name "*.sln" | head -1 | xargs basename -s .sln)
    +          SLN_PATH=$(find . -maxdepth 2 -name "*.sln" | head -1)
    +          if [[ -z "$SLN_PATH" ]]; then
    +            echo "::error::No .sln file found within depth 2"
    +            exit 1
    +          fi
    +          SLN=$(basename -s .sln "$SLN_PATH")
               echo "name=$SLN" >> "$GITHUB_OUTPUT"
               echo "Solution: $SLN"
    🤖 Prompt for AI Agents
    Verify each finding against the current code and only fix it if needed.
    
    In @.github/workflows/build.yml around lines 78 - 84, The "Resolve solution
    name" step sets SLN by finding a .sln but doesn't validate it; if none is found
    downstream steps will fail confusingly. After computing SLN in that step
    (variable SLN), add a check like if [ -z "$SLN" ]; then write a clear error to
    stderr (e.g., "No .sln file found in repo") and exit 1 so the workflow fails
    early; otherwise continue to echo "name=$SLN" >> "$GITHUB_OUTPUT" and the
    existing log line. Ensure the check references SLN and the step id (solution) so
    it's easy to locate.
    
    🤖 Prompt for all review comments with AI agents
    Verify each finding against the current code and only fix it if needed.
    
    Inline comments:
    In @.github/workflows/build.yml:
    - Around line 134-142: Avoid directly interpolating the user-controlled
    github.head_ref into the shell array; instead set it into a safe environment
    variable in a previous step (e.g., echo "PR_HEAD_REF=${{ github.head_ref }}" >>
    $GITHUB_ENV) and then reference that env var when building PARAMS (change the
    entry in PARAMS from "/d:sonar.pullrequest.branch=${{ github.head_ref }}" to use
    "/d:sonar.pullrequest.branch=${PR_HEAD_REF}" or "${PR_HEAD_REF}"). Update the
    conditional block that constructs PARAMS (the PARAMS+=(...) lines) to use the
    env var for head ref (and similarly protect any other user-provided values) so
    no untrusted string is directly interpolated into the shell script.
    
    ---
    
    Nitpick comments:
    In @.github/workflows/build.yml:
    - Around line 66-76: The workflow patches .props using VERSION but the sed
    commands only replace existing tags so <FileVersion> and <InformationalVersion>
    in Directory.Build.props remain absent; update the script to ensure those
    elements exist or are inserted when missing: after computing VERSION
    (VERSION="${{ steps.gitversion.outputs.semVer }}") adjust the find|xargs|sed
    pipeline (the current sed -e replacements) to either (a) append missing
    <FileVersion>$VERSION</FileVersion> and
    <InformationalVersion>$VERSION</InformationalVersion> into files that lack them
    or (b) change the logic to generate a minimal props fragment with all four tags
    and write/merge it into Directory.Build.props, referencing the tags <Version>,
    <PackageVersion>, <AssemblyVersion>, <FileVersion>, and <InformationalVersion>
    so explicit values are present when required.
    - Around line 179-189: The workflow currently downloads the Codacy reporter
    using the `latest` release URL (in the "Report coverage → Codacy" step), which
    is brittle; change the download URL to a pinned release (replace the
    `.../releases/latest/.../codacy-coverage-reporter-assembly.jar` URL with a
    specific tag or versioned asset) and update any references to
    `codacy-reporter.jar` accordingly (you can add a variable like REPORTER_VERSION
    and use it in the curl URL and file name) so the `java -jar codacy-reporter.jar
    report` invocation uses a reproducible, versioned reporter.
    - Around line 78-84: The "Resolve solution name" step sets SLN by finding a .sln
    but doesn't validate it; if none is found downstream steps will fail
    confusingly. After computing SLN in that step (variable SLN), add a check like
    if [ -z "$SLN" ]; then write a clear error to stderr (e.g., "No .sln file found
    in repo") and exit 1 so the workflow fails early; otherwise continue to echo
    "name=$SLN" >> "$GITHUB_OUTPUT" and the existing log line. Ensure the check
    references SLN and the step id (solution) so it's easy to locate.
    
    🪄 Autofix (Beta)

    Fix all unresolved CodeRabbit comments on this PR:

    • Push a commit to this branch (recommended)
    • Create a new PR with the fixes

    ℹ️ Review info
    ⚙️ Run configuration

    Configuration used: Organization UI

    Review profile: CHILL

    Plan: Pro

    Run ID: 4b4c9f2d-3871-4a0c-8229-3286414b8bea

    📥 Commits

    Reviewing files that changed from the base of the PR and between 9918953 and 1cb5fdf.

    📒 Files selected for processing (1)
    • .github/workflows/build.yml

    Comment thread .github/workflows/build.yml Outdated
    @gitguardian

    gitguardian Bot commented Mar 27, 2026

    Copy link
    Copy Markdown

    ⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

    Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

    🔎 Detected hardcoded secret in your pull request
    GitGuardian id GitGuardian status Secret Commit Filename
    13768420 Triggered Generic Password 1cb5fdf .github/workflows/build.yml View secret
    🛠 Guidelines to remediate hardcoded secrets
    1. Understand the implications of revoking this secret by investigating where it is used in your code.
    2. Replace and store your secret safely. Learn here the best practices.
    3. Revoke and rotate this secret.
    4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

    To avoid such incidents in the future consider


    🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

    @AppVeyorBot

    Copy link
    Copy Markdown

    @penify-dev penify-dev Bot added enhancement New feature or request Review effort [1-5]: 4 labels Mar 27, 2026
    @penify-dev

    penify-dev Bot commented Mar 27, 2026

    Copy link
    Copy Markdown
    Contributor

    PR Review 🔍

    ⏱️ Estimated effort to review [1-5]

    4, because the PR introduces a comprehensive CI workflow with multiple steps and integrations, which requires careful review to ensure all components work together correctly.

    🧪 Relevant tests

    Yes

    ⚡ Possible issues

    Configuration Complexity: The workflow has many steps and dependencies, which could lead to issues if any part fails or is misconfigured.

    Security Risk: The CouchDB password is hardcoded as 'myP@ssw0rd', which is a security concern. It should be stored in GitHub Secrets instead.

    🔒 Security concerns

    Sensitive information exposure: The CouchDB password is hardcoded in the workflow file. It should be replaced with a reference to a secret to avoid exposing sensitive information.

    @penify-dev

    penify-dev Bot commented Mar 27, 2026

    Copy link
    Copy Markdown
    Contributor

    PR Code Suggestions ✨

    CategorySuggestion                                                                                                                                    Score
    Security
    Replace hardcoded sensitive information with GitHub secrets for better security

    Consider using a more secure method for handling sensitive information like
    COUCHDB_PASSWORD instead of hardcoding it directly in the workflow file.

    .github/workflows/build.yml [28]

    -COUCHDB_PASSWORD: myP@ssw0rd
    +COUCHDB_PASSWORD: ${{ secrets.COUCHDB_PASSWORD }}
     
    Suggestion importance[1-10]: 10

    Why: Hardcoding sensitive information like passwords poses a security risk; using GitHub secrets enhances security by keeping sensitive data out of the codebase.

    10
    Enhancement
    Add coverage collection to the test command to ensure accurate reporting

    Ensure that the dotnet test command includes the --collect option to gather coverage data
    effectively.

    .github/workflows/build.yml [155]

    -dotnet test "$TEST_PROJ" \
    +dotnet test "$TEST_PROJ" --collect:"XPlat Code Coverage" \
     
    Suggestion importance[1-10]: 8

    Why: Adding the --collect option is important for accurate coverage reporting, which is crucial for maintaining code quality.

    8
    Possible issue
    Add error handling for the solution file search to prevent failures if the file is missing

    Consider adding a step to check for the existence of the .sln file before proceeding to
    avoid potential errors if the file is not found.

    .github/workflows/build.yml [81]

    -SLN=$(find . -maxdepth 2 -name "*.sln" | head -1 | xargs basename -s .sln)
    +SLN=$(find . -maxdepth 2 -name "*.sln" | head -1 | xargs basename -s .sln) || { echo "No solution file found"; exit 1; }
     
    Suggestion importance[1-10]: 7

    Why: Adding error handling for the solution file search improves robustness, preventing the workflow from failing unexpectedly if the file is missing.

    7
    Add a success check for the restore step to ensure the build process only continues if dependencies are restored correctly

    Ensure that the dotnet restore step is followed by a check to confirm that the restore was
    successful before proceeding to build.

    .github/workflows/build.yml [90]

    -run: dotnet restore
    +run: dotnet restore && echo "Restore successful" || { echo "Restore failed"; exit 1; }
     
    Suggestion importance[1-10]: 6

    Why: Adding a success check for the restore step enhances reliability by ensuring that the build process only continues if dependencies are restored correctly.

    6

    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1306 completed (commit 957cff2a88 by @gstraccini[bot])

    @codacy-production

    codacy-production Bot commented Apr 10, 2026

    Copy link
    Copy Markdown

    Not up to standards ⛔

    🟢 Coverage ∅ diff coverage · +0.11% coverage variation

    Metric Results
    Coverage variation +0.11% coverage variation (-1.00%)
    Diff coverage diff coverage

    View coverage diff in Codacy

    Coverage variation details
    Coverable lines Covered lines Coverage
    Common ancestor commit (6888d6d) 3681 1620 44.01%
    Head commit (5276ca7) 3681 (+0) 1624 (+4) 44.12% (+0.11%)

    Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

    Diff coverage details
    Coverable lines Covered lines Diff coverage
    Pull request (#866) 0 0 ∅ (not applicable)

    Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

    TIP This summary will be updated as you push new changes. Give us feedback

    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1489 completed (commit 9d9236dc49 by @gstraccini[bot])

    @codecov

    codecov Bot commented Apr 10, 2026

    Copy link
    Copy Markdown

    Codecov Report

    ✅ All modified and coverable lines are covered by tests.
    ✅ Project coverage is 40.53%. Comparing base (6461b9c) to head (daa8242).

    Additional details and impacted files
    @@            Coverage Diff             @@
    ##             main     #866      +/-   ##
    ==========================================
    - Coverage   40.62%   40.53%   -0.09%     
    ==========================================
      Files          83       83              
      Lines        3631     3631              
      Branches      519      519              
    ==========================================
    - Hits         1475     1472       -3     
    - Misses       2053     2055       +2     
    - Partials      103      104       +1     

    ☔ View full report in Codecov by Sentry.
    📢 Have feedback on the report? Share it here.

    🚀 New features to boost your workflow:
    • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1508 completed (commit 83977bc500 by @gstraccini[bot])

    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1515 failed (commit 96e8549b01 by @gstraccini[bot])

    @AppVeyorBot

    Copy link
    Copy Markdown

    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1562 failed (commit b2d85cba57 by @gstraccini[bot])

    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1591 failed (commit 7cb1db1b42 by @gstraccini[bot])

    @AppVeyorBot

    Copy link
    Copy Markdown

    Comment thread .github/workflows/build.yml Fixed
    Comment thread .github/workflows/build.yml Fixed
    @AppVeyorBot

    Copy link
    Copy Markdown

    Build CrispyWaffle 10.0.1609 failed (commit 6d708fd189 by @gstraccini[bot])

    @AppVeyorBot

    Copy link
    Copy Markdown

    Comment thread .github/workflows/build.yml Fixed
    Comment thread .github/workflows/build.yml Fixed
    @github-actions

    Copy link
    Copy Markdown
    Contributor

    Infisical secrets check: ✅ No secrets leaked!

    💻 Scan logs
    2026-05-19T13:01:07Z INF scanning for exposed secrets...
    1:01PM INF 802 commits scanned.
    2026-05-19T13:01:08Z INF scan completed in 1.29s
    2026-05-19T13:01:08Z INF no leaks found
    

    @sonarqubecloud

    sonarqubecloud Bot commented May 19, 2026

    Copy link
    Copy Markdown

    Quality Gate Passed Quality Gate passed

    Issues
    0 New issues
    2 Accepted issues

    Measures
    0 Security Hotspots
    No data about Coverage
    0.0% Duplication on New Code

    See analysis details on SonarQube Cloud

    Comment thread .github/workflows/build.yml Dismissed
    Comment thread .github/workflows/build.yml Dismissed
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Labels

    ☑️ auto-merge Automatic merging of pull requests (gstraccini-bot) enhancement New feature or request Review effort [1-5]: 4 size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

    Projects

    None yet

    Development

    Successfully merging this pull request may close these issues.

    3 participants