To summarise: I'd have prefered if there were two buttons - something like 'Rebase & run pipeline' and 'Merge without rerunning pipeline'.

100% agree (based on above reply - I haven't tested the change myself). The distinction should be clearer and users should be at least slightly discouraged by the UI from rebase + merging without rerunning a pipeline.

Also, why remove the previous option to rebase without a pipeline and also without merging? That's still potentially useful.

Found a partial workaround: in the project's group set GitLab Duo availability to "On by default" instead of "Off by default"

WARNING: (I believe) making this change will toggle all children's Duo availability setting to On!

for detailed discussion see #587739 (comment 3042448904)

Not going to wade into the deeper technical discussions here or read through the links, but maybe worth clarifying some basics:

We should allow project level override if Duo features are enabled at project level even if they're disabled at group level.

GitLab already does. That's why the group level setting is threefold:

Always off - children of the group cannot enable Duo features. Duo is completely suppressed for children by this value

The other two settings, "On by default" and "Off by default" allow children to decide independently. Implied by the name and made explicit by the the description. This setting only dictates the default value of child settings (when the parent setting is modified or when new children are added).

The misbehavior being reported here is clearly contradicting the user interface. I've only seen it apply to the auto-review toggle on projects (at least so far I haven't noticed it elsewhere), so the problem reported here may be specific and isolated.

if the parent group has duo features setting set to "Off by Default", then we should still allow users to enable the duo feature at a project level and it should work as expected, right?

Based on the docs and UI, every project and group should have a method of determining whether Duo features (or a subset as the case may be) are allowed in the project or group. The input to this is basically two-fold: are the Duo feature toggles available at the current level AND if so, are they turned on?

This is the typical pattern for settings (at least in my experience). If something depends on a given setting, you essentially check whether the setting itself is enabled first, then if it is enabled, you check its value.

If the current level Duo toggle is visible and enabled, then anything tied to that toggle at the same level should be visible.

Interesting.

I was looking for it in project settings. The project explicitly enables Duo features.

The project's direct parent group has Duo settings set to "Off by Default". In that group, the auto review setting does not appear either.

BUT, if I change the Duo settings in the group to On by Default, then the auto review setting appears in both the group and the project.

The current behavior is not correct. The project auto review setting should appear if the project itself has Duo features enabled. Requiring "On by Default" in the parent group is wrong.

Ruslan Balagansky (b976f2b3) at 27 Jan 23:35

Ruslan Balagansky (d7d5d4a2) at 27 Jan 23:34

Ruslan Balagansky (290eaba7) at 27 Jan 23:29

Note: the first examples in the docs for inputs have hyphens in input names, but later examples do not.

Ruslan Balagansky (03f720f2) at 27 Jan 22:50

Ruslan Balagansky (da3a3c30) at 27 Jan 22:49

Also: projects that previously had it enabled are no longer adding Duo as a reviewer automatically.

Adding Duo manually continues to work.

Our self-managed instance is affected also.

How about doing something like this by default:

1. Periodically update an index of "activeness" per project - some weighted measure based on number of authors, number of commits recently.
2. Use the indexed activeness measure above in ranking search results.

??

@gitlab-bot label reproduced on GitLab Self-Managed