iTunes/iTunes.Wine
Watch
1
0
Fork
You've already forked iTunes.Wine
 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

CI: weekly Woodpecker check for a new iTunes build; test install.sh on it, open a PR #13

New issue
Closed
opened 2026-10-28 17:22:40 +01:00 by The_Void · 3 comments
The_Void commented 2026-10-28 17:22:40 +01:00
Owner
Copy link

iTunes doesn't update itself under this install. 12.13.11.1 bundles no Apple Software Update (KNOWLEDGE.md → Installers), and install.sh pins one installer by URL and sha1. A new Apple build should still not go unnoticed. Installing it over the operator's prefix automatically is ruled out, because iTunes upgrades the library file one way (operator, 2026-10-28).

Detection works: curl -sIL -o /dev/null -w '%{url_effective}' https://www.apple.com/itunes/download/win64 resolves to the versioned CDN URL. On 2026-10-28 that was exactly ITUNES_URL in install.sh (…/140-75773-20260908-…/iTunes64Setup.exe).

To build: a Woodpecker cron pipeline on ci.lewd.wtf (the repo's webhook is already there), on the docker backend in fedora:44 with the rig's packages (wine/Dockerfile.fedora). It should:

  1. resolve the redirect and compare it with ITUNES_URL; when they match, stop with success;
  2. otherwise download the installer, read its ProductVersion from the bundled iTunes64.msi, and bump URL, sha1 and version in install.sh;
  3. run the bumped install.sh headless into a fresh prefix (wine/launch.sh --sh), then check that iTunes.exe and MobileDevice.dll exist, that the AMDS service has Start=4, and that iTunes is still running 90 s after start with nothing on 127.0.0.1:27015;
  4. if the checks pass, push a branch itunes-update/<version> and open a PR; if they fail, open a bug issue with the log tail. A rerun for the same version does neither twice.

The phone checks (#9) can't run in CI; after a bump they stay a manual run.

Needs the operator, in Woodpecker: a cron entry, and a secret forgejo_bot_token (Forgejo scopes write:repository + write:issue) allowed on cron and manual events.

Done when the pipeline runs green on the cron with the current pin ("up to date"), and a forced run against an older pin (12.10.11.2's URL) opens a PR for 12.13.11.1.

iTunes doesn't update itself under this install. 12.13.11.1 bundles no Apple Software Update (KNOWLEDGE.md → *Installers*), and `install.sh` pins one installer by URL and sha1. A new Apple build should still not go unnoticed. Installing it over the operator's prefix automatically is ruled out, because iTunes upgrades the library file one way (operator, 2026-10-28). **Detection works:** `curl -sIL -o /dev/null -w '%{url_effective}' https://www.apple.com/itunes/download/win64` resolves to the versioned CDN URL. On 2026-10-28 that was exactly `ITUNES_URL` in `install.sh` (`…/140-75773-20260908-…/iTunes64Setup.exe`). **To build:** a Woodpecker cron pipeline on ci.lewd.wtf (the repo's webhook is already there), on the docker backend in `fedora:44` with the rig's packages (`wine/Dockerfile.fedora`). It should: 1. resolve the redirect and compare it with `ITUNES_URL`; when they match, stop with success; 2. otherwise download the installer, read its `ProductVersion` from the bundled `iTunes64.msi`, and bump URL, sha1 and version in `install.sh`; 3. run the bumped `install.sh` headless into a fresh prefix (`wine/launch.sh --sh`), then check that `iTunes.exe` and `MobileDevice.dll` exist, that the AMDS service has `Start`=4, and that iTunes is still running 90 s after start with nothing on 127.0.0.1:27015; 4. if the checks pass, push a branch `itunes-update/<version>` and open a PR; if they fail, open a `bug` issue with the log tail. A rerun for the same version does neither twice. The phone checks (#9) can't run in CI; after a bump they stay a manual run. **Needs the operator, in Woodpecker:** a cron entry, and a secret `forgejo_bot_token` (Forgejo scopes `write:repository` + `write:issue`) allowed on `cron` and `manual` events. **Done when** the pipeline runs green on the cron with the current pin ("up to date"), and a forced run against an older pin (12.10.11.2's URL) opens a PR for 12.13.11.1.
The_Void added this to the Ready to work milestone 2026-10-28 17:22:40 +01:00
The_Void commented 2026-10-28 17:26:00 +01:00
Author
Owner
Copy link

Built in 5dd067c: .woodpecker/itunes-update.yml and ci/itunes-update.sh, plus the install.sh changes the job needs (ITUNES_VERSION; id -un instead of $USER, which a container leaves unset).

Tested on the desktop:

  • Up to date: Apple's link resolves to the pinned URL, and the script exits 0 without a token.
  • Unexpected URL: a LATEST_URL that isn't an Apple installer fails with exit 1.
  • AMDS registry check: right on the real prefix (Start=4), and also right on a Start=2 copy. The first draft looked under CurrentControlSet, which Wine's system.reg doesn't have (it uses ControlSet001). It "passed" the negative control while failing the real prefix, and the positive control caught that.
  • Version read: ProductVersion from the cached 12.13.11.1 installer reads 12.13.11.1.

Not run yet: the new-build path (download → bump → headless install → PR or issue). It needs the CI container.

Operator steps in Woodpecker (ci.lewd.wtf → iTunes/iTunes.Wine → Settings):

  1. Secrets: forgejo_bot_token, a Forgejo token with write:repository + write:issue, events cron and manual.
  2. Crons: a weekly entry (e.g. @weekly), branch master.
  3. Manual run on master with the variable LATEST_URL=https://secure-appldnld.apple.com/itunes12/001-80053-20210422-E8A3B28C-A3B2-11EB-BE07-CE1B67FC6302/iTunes64Setup.exe (12.10.11.2). That should open a PR "iTunes 12.10.11.2: install.sh", or a bug issue if install.sh fails on that build. It's a downgrade, so close the PR and delete its branch afterwards.
Built in 5dd067c: `.woodpecker/itunes-update.yml` and `ci/itunes-update.sh`, plus the `install.sh` changes the job needs (`ITUNES_VERSION`; `id -un` instead of `$USER`, which a container leaves unset). Tested on the desktop: - **Up to date:** Apple's link resolves to the pinned URL, and the script exits 0 without a token. - **Unexpected URL:** a `LATEST_URL` that isn't an Apple installer fails with exit 1. - **AMDS registry check:** right on the real prefix (`Start`=4), and also right on a `Start`=2 copy. The first draft looked under `CurrentControlSet`, which Wine's `system.reg` doesn't have (it uses `ControlSet001`). It "passed" the negative control while failing the real prefix, and the positive control caught that. - **Version read:** `ProductVersion` from the cached 12.13.11.1 installer reads `12.13.11.1`. **Not run yet:** the new-build path (download → bump → headless install → PR or issue). It needs the CI container. **Operator steps in Woodpecker (ci.lewd.wtf → iTunes/iTunes.Wine → Settings):** 1. **Secrets:** `forgejo_bot_token`, a Forgejo token with `write:repository` + `write:issue`, events `cron` and `manual`. 2. **Crons:** a weekly entry (e.g. `@weekly`), branch `master`. 3. **Manual run** on `master` with the variable `LATEST_URL=https://secure-appldnld.apple.com/itunes12/001-80053-20210422-E8A3B28C-A3B2-11EB-BE07-CE1B67FC6302/iTunes64Setup.exe` (12.10.11.2). That should open a PR "iTunes 12.10.11.2: install.sh", or a bug issue if `install.sh` fails on that build. It's a downgrade, so close the PR and delete its branch afterwards.
The_Void commented 2026-10-28 18:11:02 +01:00
Author
Owner
Copy link

Set up in Woodpecker (repo id 14):

  • Activated.
  • Secret: forgejo_bot_token, a Forgejo token scoped to this repo only (repository + issue write; checked: reads this repo, 404 on another repo, 403 on /user, and git push --dry-run succeeds), events cron + manual.
  • Cron: itunes-update @weekly on master; first run 2026-11-01 01:00 CET.

Test runs:

  • Pipeline 1: failed in setup. Woodpecker rewrites $ in commands. Fixed in d1b4ec9: setup moved to ci/setup-rig.sh.
  • Pipeline 2, LATEST_URL = 12.10.11.2: detection, download, sha1 and version all correct. The headless checks failed and the job opened #14, which is the failure path, end to end. The cause is real for that build (see #14).

Done-when, revised: the forced run opened an issue instead of the PR the done-when expected, because 12.10 genuinely fails. So the PR path is still unexercised, apart from the push credential (dry run). It will first run for real on Apple's next build, and the PR it opens is the check. The first cron run (2026-11-01) checks the up-to-date path in CI.

Set up in Woodpecker (repo id 14): - **Activated.** - **Secret:** `forgejo_bot_token`, a Forgejo token scoped to this repo only (repository + issue write; checked: reads this repo, 404 on another repo, 403 on `/user`, and `git push --dry-run` succeeds), events cron + manual. - **Cron:** `itunes-update` `@weekly` on master; first run 2026-11-01 01:00 CET. Test runs: - **Pipeline 1:** failed in setup. Woodpecker rewrites `$` in commands. Fixed in d1b4ec9: setup moved to `ci/setup-rig.sh`. - **Pipeline 2**, `LATEST_URL` = 12.10.11.2: detection, download, sha1 and version all correct. The headless checks failed and the job **opened #14**, which is the failure path, end to end. The cause is real for that build (see #14). **Done-when, revised:** the forced run opened an issue instead of the PR the done-when expected, because 12.10 genuinely fails. So the **PR path is still unexercised**, apart from the push credential (dry run). It will first run for real on Apple's next build, and the PR it opens is the check. The first cron run (2026-11-01) checks the up-to-date path in CI.
The_Void commented 2026-10-28 18:13:25 +01:00
Author
Owner
Copy link

Closed by the operator (2026-10-28). The cron, the secret and the failure path are verified (pipeline 2 → #14). The PR path is accepted as-is, untested except for the push credential: it first runs on Apple's next build, and the PR it opens is the check. If that run breaks, it gets a new issue.

Closed by the operator (2026-10-28). The cron, the secret and the failure path are verified (pipeline 2 → #14). The PR path is accepted as-is, untested except for the push credential: it first runs on Apple's next build, and the PR it opens is the check. If that run breaks, it gets a new issue.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels   
bug
An actual problem found in the code or the data

  
Claude
Filed by Claude

  
deferred
Intentionally parked - not on the critical path. Do not work unless asked

  
enhancement
An improvement to something that already works

  
epic
Tracking issue - closes only when its children do. Body indexes them

  
implementation
New implementation - a tool, script or feature that does not exist yet

  
priority/high
Do first among unblocked issues

  
priority/low
Nice to have; defer

  
priority/med
Normal priority

  
research
Reverse-engineering / an open question; 'confirmed unknown' is a legitimate outcome

  
verification
Needs a run against the real consumer - a structural check cannot close it

No labels
bug
Claude
deferred
enhancement
epic
implementation
priority/high
priority/low
priority/med
research
verification
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
iTunes/iTunes.Wine#13
No description provided.