check_patches

tech.tresbien/drupal-code-query · Verify this server

Does each composer patch still apply to the release the site installed, and is its fix already in that release? Send composer_json + composer_lock (plus patch_files for local patches) after composer update and every extra.patches entry is checked at its installed version in one call; do not download releases or run patch --dry-run yourself. - Send a package's patches in the order composer.json declares them, and keep them together: they are judged in that order because a patch manager applies them in it, so a later patch is applied to what the earlier ones left. Reordering them changes the verdicts. - items: up to 50 of {project, version, patch, title}, when you would rather name them yourself. project is the drupal.org machine name (webform) or composer name (drupal/webform), drupal or core for Drupal core; version is the composer version (1.13.0, 2.0.0-beta4, 11.4.5); patch is the diff text or its URL on www.drupal.org/files/issues or a git.drupalcode.org merge request .patch/.diff. - Per item: tag (the release tag matched, or unknown_version), applies_at (the -p level at which git apply passes, null when none), fuzzy (applied only with reduced context and whitespace ignored, as GNU patch fuzz does: review it), hunks_failed (file, line, reason), reverse_applies (the patched lines are already in the tag), mr (merge-request state when the patch is an MR URL), merged_in_version, suggested. - suggested is the verdict: shipped (fix is in the release: drop the patch), still-needed (applies cleanly: keep it), needs-reroll (neither: call reroll_patch with that item, it returns the re-rolled diff), unknown (tag or patch unresolved; see error). - next_step names the follow-up calls and the row count the report owes; counts is the verdict tally to check that table against. An item that could not be judged comes back suggested unknown with the reason in error: report it as unclear, never leave the row out. - files_shipped on a result names the patch's files the release already carries when only some of them do: the patch is partly upstream and what is left is a re-roll, not a drop. A failed hunk carries moved_to when the release keeps that file under another path. - next_step names the follow-up calls and the row count the report owes; counts is the verdict tally to check that table against. An item that could not be judged comes back suggested unknown with the reason in error: report it as unclear, never leave the row out. - hunks_shipped and files_shipped name the parts of a patch the release already carries when only some of it does: a partly-merged patch, so what is left is a re-roll rather than a drop. A failed hunk carries moved_to when the release keeps that file under another path. - next_step names the follow-up call when any item needs a re-roll. Each verdict is the result of running git apply against the release the site installed, so it replaces a hand dry-run rather than pointing at one. - core_references: what the code the patch adds references in core, checked at target_core (defaults to the lock's core): flagged lists removed or moved classes and calls whose argument count no longer fits the target signature (parent::__construct is checked against the constructor the core parent class actually declares, walking core's extends chain), each with file, line, change_record and replacement; deprecated is a short side list; checked counts references the catalog knows. Scope: added lines, direct references only (extends, implements, trait use, new, static calls, parent::__construct). A patch that does not apply carries a note instead. - Verdicts come from git apply --check against the tag's tree; a still-needed patch can still be wrong at runtime.