[BUG] audit gitlab: "internal error transforming" crash in gitlab_ci/if.rb condition_from_rule (actions_importer 1.3.22671)

[kalaiguna]

Summary

gh actions-importer audit gitlab consistently crashes with an unhandled internal error while transforming certain GitLab CI pipelines, for a specific rules:/if: construct. The audit reports the pipeline as Failed with a Ruby backtrace instead of completing conversion or falling back to Unsupported.

This is a different defect from the empty-value SecretScanner redaction corruption already reported in Discussion #357. That fix does not affect this crash, it's a separate code path entirely.

Environment

• gh actions-importer CLI (launcher): v1.3.6
• Actions Importer image: ghcr.io/actions-importer/cli:1.3.22671
• Command: gh actions-importer audit gitlab --namespace <group> --output-dir <dir>
• Host: Windows with Docker Desktop

Error

There was an internal error transforming the GitLab CI pipeline (<project>) into a GitHub Actions workflow.
Please reference '<redacted>' when requesting support.
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/if.rb:64:in `condition_from_rule'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/if.rb:44:in `block in transform'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/if.rb:44:in `map'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/if.rb:44:in `transform'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/jobs.rb:67:in `block in transform_job'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/jobs.rb:61:in `transform_job'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/jobs.rb:22:in `block in transform'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/jobs.rb:18:in `each'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/transformers/gitlab_ci/jobs.rb:18:in `transform'
/usr/local/bundle/gems/actions_importer-1.3.22671/lib/valet/services/gitlab_ci/transform_pipeline.rb:87:in `call'

Identical backtrace, same two lines (if.rb:64 in condition_from_rule, called from if.rb:44 in transform), across every affected project in our scan. This strongly suggests one unhandled case in condition_from_rule rather than many distinct bugs.

Impact

In a single GitLab group scan, this crash accounted for 30 of 30 Failed pipelines, effectively all pipeline-conversion failures in that namespace tree. 0 of these produced a config.json, converted workflow, or partial output, the job is dropped entirely with only the backtrace recorded.

What we can't share

We don't have a minimal repro .gitlab-ci.yml to attach, since we can't extract the exact rules:/if: syntax without exposing internal pipeline configuration. Given the consistent crash site, we'd expect this to reproduce with almost any GitLab CI rules: - if: <condition> construct that condition_from_rule doesn't currently handle. Grateful if someone familiar with that transformer can identify which if: syntax variants aren't covered.

Ask

• Can you confirm whether condition_from_rule (if.rb:64) has known unhandled rules:/if: syntax cases?
• Is there a way to make the audit record pipelines hitting this as Unsupported rather than crashing with no artifact, similar to how other unsupported constructs are handled elsewhere in the tool?

Happy to provide more detail (exact rule syntax category, not literal file contents) if that helps narrow it down.

[kalaiguna]

Follow-up with the confirmed root cause and a validated workaround.

Confirmed root cause

The exact exception is:

TypeError: no implicit conversion of String into Integer

This is raised by rule["if"] in condition_from_rule when rule is an Array rather than a Hash. Array#[] rejects a String key with exactly this error. This matches a GitLab CI rules: list containing a !reference entry (or another construct that resolves to a nested array of rule hashes) rather than a single rule hash, so rules.map { |rule| condition_from_rule(rule: rule) } hands condition_from_rule an Array for that entry.

Validated workaround

We patched the image to wrap transform in a rescue, downgrading an unhandled rule shape to an Unsupported condition instead of crashing the whole pipeline:

module Transformers

  module GitlabCI

    class If

      class << self

        alias_method :original_transform, :transform
 
        def transform(rules:, job_when:, only:, except:)

          original_transform(rules: rules, job_when: job_when, only: only, except: except)

        rescue StandardError => e

          Result::Unsupported.new(

            identifier: IDENTIFIER,

            comment: "Unable to map conditional expression to GitHub Actions equivalent (#{e.class}: #{e.message})",

            snippet: nil

          )

        end

      end

    end

  end

end

This only comments out the single unresolvable condition; the rest of the job still converts normally.

Result

Re-running the audit against the same GitLab group with the patched image:

• Before: 30 of 30 pipelines Failed (all crashing in condition_from_rule)

• After: 33 of 34 Successful, 1 Unsupported (a project with no .gitlab-ci.yml, unrelated), 0 Failed

Every previously-crashing pipeline now produces config.json, source.yml, and a generated workflow, with the one unresolvable condition commented out and annotated with the captured exception.

Ask

This confirms condition_from_rule doesn't handle a rules: entry that resolves to an Array (e.g. via !reference). Two possible directions for an official fix:

1. The same defensive rescue we used, converting a crash into an Unsupported condition for just that rule.

2. A proper fix that flattens/resolves !reference-style nested rule arrays before mapping over them, which would let these convert fully instead of commenting out one condition.

Happy to share more detail if useful, we don't have a minimal repro .gitlab-ci.yml we can post publicly, but the exception type and crash site above should be enough to locate the gap in condition_from_rule.