-
Notifications
You must be signed in to change notification settings - Fork 550
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
question: getting started with collate & refuse_coverage_drop on CI #986
Comments
@madisonsites - were you able to make progress on this? I'm running into the same issue. |
I would expect that require 'knapsack_pro'
SimpleCov.start 'rails' do
add_filter [
"lib/analytics/",
"lib/data_migrations/",
"lib/data_restoration/",
"lib/tasks/turnstone.rake",
"spec/",
]
refuse_coverage_drop # this line here I guess should generate "coverage/.last_run.json" file.
end
KnapsackPro::Hooks::Queue.before_queue do
SimpleCov.command_name("rspec_ci_node_#{KnapsackPro::Config::Env.ci_node_index}")
end I'm not sure thou if "coverage/.last_run.json" file would contain combined tests for each test suite run on a given CI node index when running in Knapsack Pro Queue Mode. This means RSpec hooks like I see @madisonsites uses also JUnit formatter. This is how it can be done in Queue Mode: |
@madisonsites @davidwparker Did either of you find a solution to this? |
@hannahramadan for the life of me, I can't remember how I got this working. I think it was something a bit silly - like having something in I'm so sorry that past me failed to document and follow up |
Thanks for responding @madisonsites :) It's working now! Here's the rake task for those interested:
Needed to fiddle with our CI results path, which ended up being |
Hey Howdy Hey!
I'm super appreciative of the
refuse_coverage_drop
option, but have two issues:last_run
file generated.Missing last_run file
I suspect this is coming from the fact that we are collating. I generally used this tutorial from Knapsack Pro to help knapsack, simplecov, and semaphore get along nicely through these steps...
bundle exec rake knapsack_pro:queue:rspec['--no-color --format progress --format RspecJunitFormatter --out tmp/rspec-junit/rspec.xml']
) across 6 jobs. After each job completes (not all), this is run to push up the results into a semaphore artifact (will be used in the next step):total_coverage
directory. This is where I attempted to addrefuse_coverage_drop
as I want to compare across everything together, not within the individual runs themselves (what is in each of these changes all the time and I presumed this would interfere with things).None of these attempts generated a
last_run
file.attempt one (setting
refuse_coverage_drop
IN thecollate
block:attempt two (setting
refuse_coverage_drop
AFTER thecollate
block):attempt three (setting
refuse_coverage_drop
BEFORE thecollate
block):attempt four (setting
refuse_coverage_drop
in.simplecov
):The artifacts always output as such:
![image](https://user-images.githubusercontent.com/8879305/114071442-f9788780-9855-11eb-8775-c2fa64024ca2.png)
For each of the above attempts, I checked both...
total_coverage
coverage_1
Reading/writing last_run in CI
More of a general "how is everyone else doing this?" than anything. I'd liked to dynamically generate the
last_run
file as part of our CI workflows as a step in the deploy process (meaning only when the branch being tested ismaster
) without giving write access to Semaphore (so it could commit the file each time).It seems plausible that if I can figure out the first issue, then I can easily push the
last_run
file to our project's artifacts on Semaphore (overwriting when it is the master branch only).I'm more confused about reading the last run when checking the differences for maximum coverage drop.
I see that
LastRun
uses thecoverage_path
to fetch the file. I'm aware thatcoverage_path
is configurable, but that's an all-or-nothing when I only want to "look elsewhere" for thelast_run
file - outside the standardcoverage_path
and instead to thelast_run
file in project's artifact.simplecov (0.21.2)
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin19]
rails (~> 5.1)
spec/spec_helper.rb
if it is helpful:The text was updated successfully, but these errors were encountered: