Sync docs for `only:changes`, `rules:changes` and `rules:exists`
What does this MR do and why?
Various small changes are done for the CI docs for only:changes
, rules:changes
and rules:exists
, to make them more consistent and comprehensive:
- In
rules:exists
, change doc link for Ruby'sfnmatch
from 2.7.0 to master, as was used inrules:changes
andonly:changes
.-
❔ Was linking to a fixed version of the Ruby docs a deliberate choice? If so (and if that preference still exists), two things need to be done:We should do the opposite change, and convert the other instances of master links into versioned URLsWe should confirm that the 2.7.0 version is still current (i.e. reflects the version of Ruby used by GitLab), or otherwise update it to the appropriate one.
- Edit: this has been resolved: the preference is to keep the evergreen "master" link; see comment below.
-
- In
rules:changes
andonly:changes
, move the reference to Ruby'sfnmatch
to the "Additional details" section, as is done inrules:exists
. This improves consistency and avoids giving the impression thatfnmatch
is only used for nested filename globs and not for e.g. directory or root file globs. It also uses the more detailed information (specifically, which flags are used infnmatch
) that was already present inrules:exists
.-
❓ I'd like confirmation that these flags are indeed used in all globs; it's possible that thefnmatch
invocation differs betweenrules:exists
andrules:changes/only:changes
(in which case, the difference should be made explicit).
-
- In
only:changes
, sync the format to match the near-identical text fromrules:changes
.-
❓ I didn't add the information about file paths now being able to include variables. Does that only apply torules:changes
or is it true foronly:changes
as well?
-
- In all three, link "flags" to the Ruby documentation for the filename globbing constants.
❔ in case a versioned link is preferred (see above), this link should be updated accordingly.- Edit: this has been resolved: the preference is to keep the evergreen "master" link; see comment below.
Screenshots or screen recordings
N/A
How to set up and validate locally
Preview the edited markdown file and confirm that the output in the relevant sections (rules:changes, rules:exists, only:changes) is appropriate.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Waldir Pimenta