Repository navigation
Record build customizations in BuildDetails.plist - #2577
Merged
Merged
Conversation
Customizations declare themselves with an empty <identifier>.loopcustomization file at the workspace root or a submodule root. The build-details script collects the identifiers into com-loopkit-Loop-customizations, and the diagnostic report lists them.
marionbarker
pushed a commit
to loopandlearn/customization
that referenced
this pull request
Oct 14, 2026
* basal_lock: update nextdev patch for Loop plugin picker Loop next-dev PR LoopKit/Loop#2572 (plugin picker sheet with manufacturer groups and subtitles) reworked SettingsView, so nextdev_basal_lock.patch stopped applying. Rebase the SettingsView hunks onto the plugin picker and move the old patch to basal_lock/archive/nextdev_basal_lock_20d597f.patch, named for the last Loop commit it applied to. The rebased patch applies on top of nextdev_profiles.patch and vice versa, so no next-dev combination patches are needed. * Add .loopcustomization marker to every active patch LoopKit/Loop#2577 records each <identifier>.loopcustomization file found at the workspace root or a submodule root in BuildDetails.plist, the diagnostic report and the analytics instantiation event. Every active patch now creates an empty <folder>.loopcustomization at the LoopWorkspace root, named after its customization folder. Combination patches carry only the marker of their own folder. Each patch is applied and reverted as a unit, so the marker follows the customization, and the distinct file names keep patches from conflicting with each other. The unmarked versions are kept as archive/<name>_nomarker.patch so that workspaces with an unmarked patch applied show "Update available". * xdrip_cgm: update nextdev patch for current next-dev Next-dev replaced the LibreCRKit submodule with RoundWhiteDiscKit, so the nextdev patch no longer applied and the main/dev patch was used instead, which fails to build on next-dev. The patch makes the same change with updated context. The old patch is moved to the archive, named for the last LoopWorkspace commit it applied to.
ps2
added a commit
that referenced
this pull request
Oct 18, 2026
Backport of #2577 from next-dev. capture-build-details.sh records each *.loopcustomization file that the LoopWorkspace customization script adds, the diagnostic report lists them, and an issue report sends them as "customizations" with the other build details.
ps2
added a commit
that referenced
this pull request
Oct 18, 2026
* Require iOS 17.6 The project-level 15.1 setting overrode Loop.xcconfig, so the app still targeted iOS 15.1. Remove it and raise Loop.xcconfig to 17.6, which matches next-dev and the plugins that already require it. * Submit issue reports to the LoopKit developers Backport of #2585 from next-dev. Settings > Support > Report Issue now opens one screen where the person either submits a report to ingest.loopkit.org/v1/issues or exports Loop's diagnostic report locally, which opens the existing issue report screen. A submitted report has a description, optional title and screenshots. It is anonymous unless the person fills in a name, email, Zulip or GitHub contact, and the analytics device ID is never sent. Build and device details (version, build, branch, revisions, device model, OS, pump and CGM model) are listed on the screen and sent with every report. Loop's diagnostic report is attached as text by default; the toggle says it contains health data. Photos other than PNG are converted to JPEG. dev has no build customizations list, so that context key is left out. The diagnostic report and the pump and CGM models come from the settings delegate, since dev's settings view model has no device manager. * Include build customizations in issue reports Backport of #2577 from next-dev. capture-build-details.sh records each *.loopcustomization file that the LoopWorkspace customization script adds, the diagnostic report lists them, and an issue report sends them as "customizations" with the other build details.
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
1 participant
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.
Gives build customizations (patches people apply to the workspace or a submodule) a way to identify themselves, so they can be tracked in analytics and show up in diagnostic reports.
Convention: a customization adds an empty file named
<identifier>.loopcustomizationat the workspace root or at the root of the submodule it patches, e.g.Loop/my_feature.loopcustomization. Each customization adds its own new file, so any number of patches can be applied together without conflicting.capture-build-details.shfinds those files (workspace root and submodule roots; the Loop folder itself for a standalone build) and writes the sorted identifiers tocom-loopkit-Loop-customizationsinBuildDetails.plist. The key is always written, as an empty array when there are none.BuildDetails.customizationsreads them back.LoopKit/LoopSupport#36 sends them on the analytics instantiation event.
Tested by running the script against a scratch plist with markers at the workspace root and in LoopKit (both collected, sorted), then with none (empty array), and the workspace build succeeds.