Conversation
2ebacf1 to
6a1b4e6
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3719 +/- ##
=======================================
Coverage 89.77% 89.77%
=======================================
Files 174 174
Lines 5054 5055 +1
Branches 489 492 +3
=======================================
+ Hits 4537 4538 +1
Misses 517 517 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
506331e to
b9f21a1
Compare
4 tasks
pullRequests.draft should not be wiped when combined with _unset_ config
b9f21a1 to
54d8318
Compare
…mbined with _unset_ config This fixes a bug that came in with the initial introduction of the `pullRequests.draft` config setting with this PR: * #3628 The bug was that when combining global & local repo config, the result of combining `pullRequests.draft = true` with a config with _no_ setting for `pullRequests.draft` would be that `pullRequests.draft` was _unset_ (ie given the value `None`, rather than `Some(true)`. This is because of the behaviour of `.mapN()`, which I hadn't really thought through: https://github.com/scala-steward-org/scala-steward/blob/373d5a70533a024389bb93f5028d0fee81a6cbd6/modules/core/src/main/scala/org/scalasteward/core/repoconfig/PullRequestsConfig.scala#L66 ...in retrospect, it's not too surprising that `.mapN()` on two `Option`s only produces a populated `Some` if _both_ the inputs are `Some` - which is not the behaviour we want here. For us, if only _one_ of the configs has a value set, we definitely want to use that value. In the end, the neatest way I could find to get the desired behaviour was to remove the thing stopping us from having a `Monoid[Option[Boolean]]` - ie that there is no _general_ `Monoid[Boolean]` (there is no _one_ correct way to combine two `Boolean`s). We can create a specific one for this case, that says `Boolean`s should be combined with logical-`OR` (rather than `AND`, for instance) - and only expose it in the very narrow scope of where we want to use it. * guardian/scala-steward-public-repos#102 (comment)
54d8318 to
6069792
Compare
mzuehlke
approved these changes
Oct 2, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes a bug that came in with the initial introduction of the
pullRequests.draftconfig setting:The bug was that when combining global & local repo config, the result of combining
pullRequests.draft = truewith a config with no setting forpullRequests.draftwould be thatpullRequests.draftwas unset (ie given the valueNone, rather thanSome(true).Here's an example of where this was a problem in the wild:
Cause
This arose because of the behaviour of
.mapN(), which I hadn't really thought through:scala-steward/modules/core/src/main/scala/org/scalasteward/core/repoconfig/PullRequestsConfig.scala
Line 66 in 373d5a7
...in retrospect, it's not too surprising that
.mapN()on twoOptions only produces a populatedSomeif both the inputs areSome- which is not the behaviour we want here. For us, if only one of the configs has a value set, we definitely want to use that value.Fix
In the end, the neatest way I could find to get the desired behaviour was to remove the thing stopping us from having a
Monoid[Option[Boolean]]- ie that there is no generalMonoid[Boolean](there is no one correct way to combine twoBooleans). We can create a specific one for this case, that saysBooleans should be combined with logical-OR(rather thanAND, for instance) - and only expose it in the very narrow scope of where we want to use it.