#132 clarify when reports are generated and when minimums are applied

[RichardBradley]

Fixes #132

[sksamuel]

Can we split this up as 1.3.2 isn't released yet so updating readme at same time will mean more issues :)

[RichardBradley]

Can we split this up as 1.3.2 isn't released yet so updating readme at same time will mean more issues :)

Sure, I've split the branch into two commits - one with the code changes and one with the README and version changes. Is that what you need, or did you want two separate PRs?

I don't think I understand why though...
The PR includes a version number change, so I would expect the workflow to be something like:

• PR is merged
• (for a very short time) the README at https://github.com/scoverage/sbt-scoverage displays the new version number (1.3.2) and the new documentation about when reports are generated. Anyone who tries to use 1.3.2 will be disappointed.
• 1.3.2 is published, either by you or by your automated build systems
• The README on github is now correct

Did you want to merge this and not publish it or something? Am I just being dumb?

https://travis-ci.org/scoverage/sbt-scoverage/builds/76252063

There was a build failure -- I'll check. This test passes for me locally though. I'll look into it.

[sksamuel]

Because I can't release until on my proper computer, and I'll get 100
emails guaranteed :)

On 19 August 2015 at 16:38, Richard Bradley [email protected]
wrote:

Can we split this up as 1.3.2 isn't released yet so updating readme at
same time will mean more issues :)

Sure, I've split the branch into two commits - one with the code changes
and one with the README and version changes. Is that what you need, or did
you want two separate PRs?

I don't think I understand why though...
The PR includes a version number change, so I would expect the workflow to
be something like:

• PR is merged
• (for a very short time) the README at
  https://github.com/scoverage/sbt-scoverage displays the new version
  number (1.3.2) and the new documentation about when reports are generated.
  Anyone who tries to use 1.3.2 will be disappointed.
• 1.3.2 is published, either by you or by your automated build systems
• The README on github is now correct

Did you want to merge this and not publish it or something? Am I just
being dumb?

https://travis-ci.org/scoverage/sbt-scoverage/builds/76252063

There was a build failure -- I'll check. This test passes for me locally
though. I'll look into it.

—
Reply to this email directly or view it on GitHub
#133 (comment)
.

[sksamuel]

I guess I can just leave it parked here until I'm ready.

On 19 August 2015 at 16:40, Stephen Samuel (Sam) [email protected] wrote:

Because I can't release until on my proper computer, and I'll get 100
emails guaranteed :)

On 19 August 2015 at 16:38, Richard Bradley [email protected]
wrote:

Can we split this up as 1.3.2 isn't released yet so updating readme at
same time will mean more issues :)

Sure, I've split the branch into two commits - one with the code changes
and one with the README and version changes. Is that what you need, or did
you want two separate PRs?

I don't think I understand why though...
The PR includes a version number change, so I would expect the workflow
to be something like:

• PR is merged
• (for a very short time) the README at
  https://github.com/scoverage/sbt-scoverage displays the new version
  number (1.3.2) and the new documentation about when reports are generated.
  Anyone who tries to use 1.3.2 will be disappointed.
• 1.3.2 is published, either by you or by your automated build systems
• The README on github is now correct

Did you want to merge this and not publish it or something? Am I just
being dumb?

https://travis-ci.org/scoverage/sbt-scoverage/builds/76252063

There was a build failure -- I'll check. This test passes for me locally
though. I'll look into it.

—
Reply to this email directly or view it on GitHub
#133 (comment)
.

[RichardBradley]

I guess I can just leave it parked here until I'm ready.

That's what I was expecting :-)

[RichardBradley]

There was a build failure -- I'll check

I'll come back to this tomorrow or later this week.

[RichardBradley]

There was a build failure

Found the problem -- the "scripted" test "bad-coverage" is checking that the coverage minimums are enforced. It ran "sbt clean coverage test" and expected a failure.

I've updated it to run "sbt clean coverage test coverageReport" as per the new design discussed at the top of this thread.

(I didn't know about the "scripted" sbt tests plugin -- that's pretty useful.)

[rorygraves]

@RichardBradley This has a merge conflict, can you please rebase?

[RichardBradley]

I've pushed a merge
(Let me know if you'd much rather have a rebase)

[RichardBradley]

OK to merge now?

[sksamuel]

Thanks richard