Repository navigation
v1.6.2 — Xcode projects with package plugins, and no score that was not earned #179
ericodx
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
This release makes Xcode projects whose packages apply a build tool plugin testable, and stops the tool from printing a score it did not earn. Before,
xcodebuildstopped atValidate plug-inwaiting for a trust prompt a headless build cannot answer: every mutant came back unviable and the run printed 100%. Now plugin and macro validation is skipped, a project that does not build stops the run with the compiler error, a run where no mutant could be tested showsn/a, and a build that runs out of time stops the run instead of counting its mutants as detected. A new--xcodebuild-argflag passes extra arguments to everyxcodebuildcall. Thanks to @mifkata for the report and for testing every fix on a real project (#176).Bug fixes
Xcode projects with package plugins (#176)
build-for-testingpasses-skipPackagePluginValidationand-skipMacroValidation. A project whose packages apply a build tool plugin, such as SwiftLint or the OpenAPI generator, no longer stalls atValidate plug-in// swiftlint:disable alland// swiftlint:enable all. A SwiftLint build tool plugin used to lint the schematized code and fail the build on its generated identifiers, which made every mutant unviable. The integrity check compares the files without the wrapperNo score that was not earned (#176)
1with the compiler output, which--keep-logsalso writes tobaseline.log. Before, every mutant was reported unviablen/ain the console, HTML and Markdown reports, and--min-scoreand--max-score-dropfail on it. Before, it printed 100%--build-timeoutstops the run withBuild did not finish within Ns. Raise --build-timeout.It used to record its mutants asTimeout, which counts as detected, so a project whose fallback builds all ran out of time reported 100%Timed-out Xcode builds (#176)
SWBBuildServiceand theswift-frontendprocesses it starts run in their own process groups, so the signal sent toxcodebuild's group missed them, and they kept writing into the sandbox after the tool had removed it (225 MB to 1.3 GB per run). They are now stopped and killed firstCache
xcodebuildarguments, so changing them tests every mutant againunviableverdicts from the plugin validation, which would never be tested again. They are discarded once, with the usual warningNew
Extra
xcodebuildarguments (#176)--xcodebuild-arg <arg>, repeatable, and thexcodebuild-argskey in.swift-mutation-testing.ymlpass arguments to everyxcodebuildcall of a run: the shared build, the test runs, the fallback builds, and the builds and tests of incompatible mutants-scheme,-destinationor-derivedDataPath, are refused with exit code1. So is the flag on a package, since SwiftPM builds take noxcodebuildargumentUpgrading
1. Before, it finished with every mutant unviable and a 100% score1. If a fallback or incompatible-mutant build needs more time than the default 120 s, raise--build-timeoutn/a. A quality gate with--min-scoreor--max-score-dropfails when no mutant could be tested, and a baseline written from such a run has no scoreTest coverage
This repository's own score on the
defaulttier is still 99.8%, from the self-run of 2026-10-13: 1672 mutants, 98.8% over every operator. That is the README badge.Known issues
Signed-Releasesand reproducible build provenance are not in placeRequirements
Installation
See the Installation Guide for Homebrew, pre-built binary, and build from source instructions.
What's Changed
Full Changelog: v1.6.1...v1.6.2
This discussion was created from the release v1.6.2 — Xcode projects with package plugins, and no score that was not earned.
All reactions