the version currently there is over 2 years old (0.1.1). The readme on github doesn't work with that version.

I'm loving having annotations in my Buildkite builds, but is there a way to disable output at the command line when not running this within a buildkite session?

Or perhaps just recommend in the README to only invoke this inside buildkite, perhaps with a custom wrapper script?

I'm in a project with ruby 2.4 and I'm getting

SyntaxError:
   /opt/whatever/webapp/vendor/bundle/ruby/2.4.0/gems/simplecov-buildkite-0.2.0/lib/simplecov/buildkite/profiles.rb:112: syntax error, unexpected keyword_rescue, expecting keyword_end
   rescue RuntimeError => error
   ^

that's because rescue inside blocks is only allowed since ruby 2.5.
Because of this, it would be good to add the restriction to the gemspec file, so the gem isn't installed for uncompatible ruby versions.

Currently, if no groups exist, an empty unordered list is created. This should probably simply return the main summary’s content and nothing else.

hi,

I have followed the steps and running the build using buildkite, however not getting an annotation displayed.

This is what I have in my test_helper.rb

`ENV["RAILS_ENV"] ||= "test"

require "simplecov"
require "simplecov-buildkite"

SimpleCov.start "rails" do
load_profile "buildkite"

add_filter "/bin/"
add_filter "/db/"
add_filter "/spec/" # for rspec
add_filter "/test/" # for minitest

formatter SimpleCov::Formatter::MultiFormatter.new(
[
SimpleCov::Formatter::HTMLFormatter,
SimpleCov::Buildkite::AnnotationFormatter,
])
end`

This is what is outputted from my test step, but not seeing any annotation.

Because the spec suite’s coverage data fixtures aren’t based on any files that exist, and because SimpleCov requires a file to exist on-disk for it to process any coverage data representing it, the coverage data is not actually processed: the data which is present should show 50% (2/4) coverage, not 100% (0/0), if the files existed.

It will become more important to have a proper spec suite which renders realistic results for features to come in the future.

First -- your plugin is awesome and we really appreciate you releasing it!!!

Having some trouble now that git mirrors is enabled the git commands are broken.. I think this is related buildkite-plugins/docker-compose-buildkite-plugin#225

Sounds like there is some kind of fix for this but we couldn't figure out how to do it. Do you think there is a way to update this plugin to tolerate git mirrors being enabled?

Thank you so much for releasing this OSS!

SimpleCov::Buildkite profile initialising...

  | branch_name=dev-#x79zf1-add-code-coverage-to-ci
  | base_branch_name=master
  | current_commit=6f6a95dec90d54131c042b62332b0126d8e61106
  | error: object directory /var/lib/buildkite-agent/git-mirrors/git-github-com-ollieorder-ollieorder-git/objects does not exist; check .git/objects/info/alternates
  | current_commit_short=6f6a95d
  | error: object directory /var/lib/buildkite-agent/git-mirrors/git-github-com-ollieorder-ollieorder-git/objects does not exist; check .git/objects/info/alternates
  | fatal: bad object 6f6a95dec90d54131c042b62332b0126d8e61106
  | Command exited with status 128: git diff --name-only --diff-filter=d 6f6a95dec90d54131c042b62332b0126d8e61106

Hi! This is a pretty cool gem! I like the formatting overall, it's nice and simple.

One issue that I've noticed is that the "files changed" metrics are comparing against ENV['BUILDKITE_PULL_REQUEST_BASE_BRANCH'] which might not actually be the upstream's most recent version of that branch. E.g. If my base branch is main, unless I check out that branch, pull from origin, and then check out the target branch, main could be stale, if for instance my CI is running in an image that gets built somewhat infrequently. I'm not sure if it would be enough to just add in origin to this piece of code here, or if it would possibly depend on what the remote repository is named...

      merge_base = git_merge_base(current_commit,
                                  "origin",)
                                  base_branch_name)

I suppose I can work around it by ensuring that I do a git checkout main && git pull origin main before checking out the target branch in the Buildkite checkout hook, but thought it would be nice if this gem handled it automatically - otherwise checkout out the upstream branch isn't strictly necessary so it'd probably save a tiny bit of time to not have to do it.

Thank you!

Edit: Hmm, I am realizing that I don't need to actually check out the main branch to update it, I can just update the local reference by doing git fetch origin main:main. That seems good enough to work around the issue for now. This caught me by surprise when I first ran into it, but it does make sense that it works this way currently.