Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 9 additions & 5 deletions .github/workflows/rubygems.yml
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,9 @@ on:
jobs:
test:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write
strategy:
matrix:
ruby-version: ['2.7', '3.0', '3.1', '3.2', '3.3']
Expand Down Expand Up @@ -52,13 +55,14 @@ jobs:
TEST_CHECK_EXISTENCE_PARENT_FOLDER_ID: "${{ secrets.TEST_CHECK_EXISTENCE_PARENT_FOLDER_ID }}"
TEST_CHECK_EXISTENCE_FILE_TITLE: "${{ vars.TEST_CHECK_EXISTENCE_FILE_TITLE }}"
TEST_CHECK_EXISTENCE_FOLDER_TITLE: "${{ vars.TEST_CHECK_EXISTENCE_FOLDER_TITLE }}"
# https://github.com/simplecov-ruby/simplecov#json-formatter
CC_TEST_REPORTER_ID: "${{ secrets.CC_TEST_REPORTER_ID }}"

- uses: paambaati/codeclimate-action@v9.0.0
- name: Upload coverage to Qlty Cloud
uses: qltysh/qlty-action/coverage@v2
if: matrix.ruby-version == '3.1'
env:
CC_TEST_REPORTER_ID: "${{ secrets.CC_TEST_REPORTER_ID }}"
with:
oidc: true
files: coverage/coverage.json
Copy link

Copilot AI Apr 11, 2026

Choose a reason for hiding this comment

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

The workflow uploads coverage/coverage.json, but the repo’s SimpleCov setup (spec/spec_helper.rb) only calls SimpleCov.start and does not configure the JSON formatter, so coverage/coverage.json is unlikely to be generated. Either update the SimpleCov configuration to emit coverage/coverage.json via simplecov_json_formatter, or point files: at the SimpleCov output file that is actually produced (e.g., .resultset.json if that’s what Qlty expects for format: simplecov).

Suggested change
files: coverage/coverage.json
files: coverage/.resultset.json

Copilot uses AI. Check for mistakes.
format: simplecov
Comment on lines +59 to +65
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.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

For qltysh/qlty-action/coverage@v2, what is the default behavior when upload/auth fails, and is there a supported input like skip-errors to avoid failing CI?

💡 Result:

The default behavior of qltysh/qlty-action/coverage@v2 when upload/auth fails is to fail the GitHub Action step, causing the CI workflow to fail. This is evidenced by GitHub issue #145 where the action crashes on upload attempt with an authentication-related panic/error, and official docs describe authentication failures (e.g., invalid token, OIDC issues on forks) as errors that prevent successful uploads. There is a supported input skip-errors that can be set to true to avoid failing CI on certain errors. In issue #145, a user explicitly used skip-errors: false (implying default may be true or configurable), and the action continued processing files before failing on upload/parsing. Setting skip-errors: true likely skips upload failures without failing the step, though official action.yml/docs do not explicitly list all inputs (action is a wrapper around qlty coverage publish, which has --no-validate but no direct skip-auth flag).

Citations:


🏁 Script executed:

# First, let's examine the actual workflow file to see the current state
cat -n .github/workflows/rubygems.yml | sed -n '59,65p'

Repository: bskim45/fastlane-plugin-google_drive

Length of output: 361


🏁 Script executed:

# Check if there's any documentation or action.yml in the repo related to qlty-action
find . -type f -name "*.yml" -o -name "*.yaml" -o -name "action.yml" | xargs grep -l "qlty" 2>/dev/null | head -20

Repository: bskim45/fastlane-plugin-google_drive

Length of output: 112


🌐 Web query:

qltysh/qlty-action/coverage@v2 skip-errors input documentation

💡 Result:

The qltysh/qlty-action/coverage@v2 GitHub Action is a reusable action for uploading code coverage data to Qlty Cloud. It requires a free Qlty Cloud account. Usage example from official Qlty documentation: - uses: qltysh/qlty-action/coverage@v2 with: oidc: true files: coverage/lcov.info Or with token: - uses: qltysh/qlty-action/coverage@v2 with: token: ${{ secrets.QLTY_COVERAGE_TOKEN }} files: coverage/lcov.info The skip-errors input is shown in a real-world usage example from GitHub issue #145 in the repository: - uses: qltysh/qlty-action/coverage@v2 with: oidc: true files: app/coverage.lcov skip-errors: false add-prefix: app/ This suggests skip-errors is a boolean input (default likely true) that controls whether to skip (continue on) errors during coverage processing or upload, such as parsing failures. Setting it to false makes the action fail on errors, as seen in the crash report where a parsing panic occurred. Other common inputs from examples and CLI mapping (qlty coverage publish): - token: Qlty coverage token (alternative to oidc) - oidc: Use OIDC authentication (boolean) - files: Path(s) to coverage report file(s) - tag: Coverage tag for organization - add-prefix: Prefix to add to file paths - total-parts-count: For server-side merging - format: Coverage format (inferred or specified) The action wraps the qlty coverage publish CLI command, passing inputs as flags. Full inputs are defined in the action's action.yml file (not directly surfaced in search snippets), but skip-errors allows error-tolerant uploads, useful for malformed reports. For complete documentation, see Qlty Docs: https://docs.qlty.sh/coverage/quickstart and repository: https://github.com/qltysh/qlty-action

Citations:


🌐 Web query:

qltysh/qlty-action action.yml inputs skip-errors default value

💡 Result:

The default value for the 'skip-errors' input in qltysh/qlty-action's action.yml is false. This input is used in the qltysh/qlty-action/coverage action to control whether to skip errors during coverage upload (e.g., parsing failures). It is explicitly set to skip-errors: false in usage examples from issue reports.

Citations:


🌐 Web query:

GitHub Actions continue-on-error vs skip-errors best practice workflow reliability

💡 Result:

skip-errors is not a recognized GitHub Actions feature. The standard mechanism for handling errors without halting execution is continue-on-error: true, available at both job and step levels. Key differences and behaviors from official documentation and community sources: - Step level (jobs.<job_id>.steps[*].continue-on-error): When true, a step failure does not fail the job. The step's outcome remains 'failure' (accessible via steps.<step_id>.outcome), but conclusion is 'success'. Subsequent steps run normally. The job shows as failed if any non-continued step fails. Use for non-critical steps like optional coverage checks or notifications, where you want to upload artifacts/logs despite failure. Example: - name: Optional check id: check continue-on-error: true run: exit 1 - name: Upload if failed if: steps.check.outcome == 'failure' run: echo "Failed but continuing" - Job level (jobs.<job_id>.continue-on-error): When true, a job failure does not fail the workflow. The job shows as failed (red X), but dependent jobs (via needs) can run if their if allows (e.g., if: always). Use for experimental matrix jobs. Example for matrix: test: continue-on-error: ${{ matrix.experimental }} strategy: matrix: experimental: [true, false] For workflow reliability best practices: - Prefer if: success || failure or if: !cancelled on cleanup/upload steps over continue-on-error at step level. This runs always (except cancel), keeps failure visible, no special outcome checking needed. Sources confirm this shows correct failure status while continuing. - For matrices: strategy.fail-fast: false + no continue-on-error lets all jobs run, workflow fails if any does (preferred for full visibility). - Use steps..outcome to check true failure after continue-on-error. - Avoid overusing continue-on-error as it can mask issues; combine with notifications (e.g., PR comments on failure). - Set timeout-minutes and retry for resilience. This ensures reliability: failures are visible, workflows continue for cleanup/completeness, no silent ignores.

Citations:


Make coverage upload explicitly non-blocking (per PR objective).

On lines 59-65, this step can still fail the job when Qlty Cloud/OIDC/project setup is incomplete. The action defaults to failing on errors (skip-errors defaults to false), so add a hard non-blocking guard at the GitHub Actions level and skip when the coverage artifact is missing.

Proposed workflow hardening
       - name: Upload coverage to Qlty Cloud
         uses: qltysh/qlty-action/coverage@v2
-        if: matrix.ruby-version == '3.1'
+        if: matrix.ruby-version == '3.1' && hashFiles('coverage/coverage.json') != ''
+        continue-on-error: true
         with:
           oidc: true
           files: coverage/coverage.json
           format: simplecov
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/rubygems.yml around lines 59 - 65, The "Upload coverage to
Qlty Cloud" step can fail the job when Qlty/OIDC or project setup is incomplete;
make it non-blocking by adding continue-on-error: true and pass the action input
skip-errors: true to qltysh/qlty-action/coverage@v2, and avoid running it when
the artifact is missing by adding a prior step (e.g., "check-coverage-artifact")
that tests for coverage/coverage.json and sets outputs.coverage_exists, then
change this step's if to: matrix.ruby-version == '3.1' &&
steps.check-coverage-artifact.outputs.coverage_exists == 'true' so the upload
only runs when the file exists and never fails the workflow.


build_and_publish:
name: Build and Publish
Expand Down
Loading