Gitlab Integration: Nil commit_sha crashes Pronto

[Stéphane Akkaoui]

Synopsis:

A Message with a commit_sha=nil generate an invalid Gitlab URL, resulting in Pronto failing.

Description:

We have a CI set up at Gitlab public cloud, running Pronto and Rubocop at each push. Everything worked fine until a month ago.

We had the following error:

$ bundle exec pronto run -f gitlab -c remotes/origin/staging
bundler: failed to load command: pronto (/builds/good-terms/coton/vendor/bundle/ruby/2.6.0/bin/pronto)
Gitlab::Error::NotFound: Server responded with code 404, message: 404 Commit Not Found. Request URI: https://gitlab.com:443https://gitlab.com/api/v4/projects/good%2Dterms%2Fcoton/repository/commits/comments?per_page=500
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/gitlab-4.11.0/lib/gitlab/request.rb:67:in `validate'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/gitlab-4.11.0/lib/gitlab/request.rb:46:in `block (2 levels) in <class:Request>'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/gitlab-4.11.0/lib/gitlab/client/commits.rb:76:in `commit_comments'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto/gitlab.rb:5:in `commit_comments'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto/formatter/commit_formatter.rb:6:in `block in existing_comments'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto/formatter/commit_formatter.rb:6:in `each'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto/formatter/commit_formatter.rb:6:in `flat_map'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto/formatter/commit_formatter.rb:6:in `existing_comments'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto/formatter/git_formatter.rb:6:in `format'
  /builds/good-terms/coton/vendor/bundle/ruby/2.6.0/gems/pronto-0.10.0/lib/pronto.rb:67:in `block in run'
...

We were thinking of a configuration issue, having two protocols and two domains in the reported URL. Then we were looking for something with the project slug or Gitlab changing their APIs.

And then we noticed a missing commit number in the problematic URL.

Digging through Pronto, we discovered that one of the messages had a nil commit_sha:

#<Pronto::Message:0x00007fbedb092d50 
  @path="Gemfile.lock", 
  @line=#<struct Pronto::Git::Line 
    line=#<Pronto::BundlerAudit::GemfileLock::Scanner::Line:0x00007fbedb092df0 
      @line_number=33>,
    patch=#<Pronto::BundlerAudit::GemfileLock::Scanner::Patch:0x00007fbedb092dc8>,
    hunk=nil>, 
  @level=:error,
  @msg="Name: nokogiri\nVersion: 1.10.3\nAdvisory: CVE-2019-5477\nCriticality: Unknown\nURL: https://github.com/sparklemotion/nokogiri/issues/1915\nTitle: Nokogiri Command Injection Vulnerability via Nokogiri::CSS::Tokenizer#load_file\nSolution: Upgrade to >= 1.10.4.",
  @runner=Pronto::BundlerAudit,
  @commit_sha=nil
>

We are still digging to see how among all the gems involved (see below) is responsible for not being able to find a valid commit sha to report, and why. At least, we think Pronto should render a different, more specific error message when this happens.

We are willing to work on a fix; please advise on the expected Pronto behavior.

Using:

    pronto (0.10.0)
    pronto-bundler_audit (0.4.0)
    pronto-flay (0.10.0)
    pronto-rubocop (0.10.0)
    rubocop (0.72.0)
    rubocop-performance (1.4.0)
    rubocop-rails (2.2.0)