Repository navigation
Conversation
'Common.list' carried the fonts - 'lm', 'lm-math', 'noto', 'notomath', 'libertinus-otf' - but nothing that loads them. 'pytooling.sty' requires 'unicode-math' and 'newunicodechar' directly, 'unicode-math' needs 'fontspec', and LuaTeX's OpenType loader is 'luaotfload' with 'lualibs'. None of them was listed, so the image obtained them at run time through '[MPM]AutoInstall=1', which needs a package database the container never refreshed. 'luatex85' comes from the consumer side: Sphinx's LaTeX output requires it for LuaTeX >= 0.85, and 'pytooling/miktex:sphinx' has been failing there with "module 'luaotfload-main' not found" and "Sphinx requires luatex85.sty". Unicode font support belongs to the base image rather than to the Sphinx variant, so the six packages go into 'Common.list'. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
Every image build fails in 'miktex packages install' with "Sorry, but: The requested package is unknown.", and the '|| cat /var/log/miktex/mpmcli_admin.log' fallback prints "No such file or directory", so the log never names the package. Checking the repository manifest itself does: 'miktex-zzdb1-2.9.tar.lzma' holds 'mpm.ini' with 9099 package sections, and of the 107 entries in 'Common.list' exactly one is missing from it - 'l3backend'. 'l3kernel' and 'l3packages' are both present; 'l3kernel' takes its place, 'l3packages' stays as it was. Which mirror a run happens to visit decides whether it fails: runs at 18:46 and 18:59 UTC passed, and 19:08 (tug.ctan.org) and 19:20 (mirrors.rit.edu) failed with the same list. The mirrors that already carry the current database reject the package, so this gets worse as the rest catch up. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
'Docker.buildx.sh' counts nothing: it sets 'Counter_Error=0', recognizes build errors with 'Pattern_ERROR' and exits with 'exit $Counter_Error', but the branch matching that pattern only prints the line in red. The counter stays 0, so the filter always exits 0. Both build steps pipe 'docker buildx build' into it and carry no 'shell:' key, so they run under 'bash -e' without '-o pipefail' and the step's status is the filter's. A failed build therefore passed its own step, and the job died in the next one with 'No such image: <image>' and "numfmt: invalid number: ''" - an error naming the wrong step, which reads like a tagging problem. Run 35138670702 is an example: a package missing from 'Common.list' looked like a fault of the change under test. The error branch increments the counter again, and both build steps set '-o pipefail' so that 'docker' failing without printing 'ERROR:' is caught too. Checked against the filter directly: a clean log exits 0, a log with two 'ERROR:' lines exits 2, and the same log exits 0 on the current 'dev'. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
pytooling-claude
Bot
added
Font: OTF
Co-authored-by: Patrick Lehmann <Paebbels@gmail.com>
Every run tagged its images 'dev', 'release' or 'latest' before a single check
had run, and pushed them right after the build. A push to any branch therefore
replaced 'miktex:dev' and 'miktex:sphinx-dev' for everyone, and an image that
failed its checks stayed under an official tag until the next run overwrote it.
The images are now built, pushed and tested as 'ci-<short sha>' and
'ci-<variant>-<short sha>'. 'SanityCheck', 'Document' and 'SanityCheck-Sphinx'
consume those, so the promoted image is the one that was tested, bit for bit.
The new 'Publish' job moves the official tags onto it with
'docker buildx imagetools create', which copies the manifest inside the
registry: no pull, and the tags share a digest. It needs every checking job,
and runs only where an official tag is defined - a release tag ('latest'), a
release commit ('release') and the 'dev' branch ('dev'). On every other branch
'publish_official' is 'false' and no official tag is written at all.
'TriggerTaggedRelease' and 'ReleasePage' now need 'Publish', so a release is
neither tagged nor published when its images didn't reach the registry.
Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
'PrepareJob.yml', 'TagReleaseCommit.yml' and 'PublishReleaseNotes.yml' were pinned to '@r7' while '@r8' is the current major line. 'TagReleaseCommit.yml' is identical in both. The other two differ in one pattern only: 'FATHER_SHA' became 'SECOND_PARENT_SHA', and with it '"{FATHER_SHA}" == ""' became '"${SECOND_PARENT_SHA}" == ""' - the '@r7' version compares a literal string, so the guard for an empty second parent never fires. That is the step which finds the release pull-request behind a merge commit, and its description is what becomes the release notes. No input, output or trigger differs between the two lines. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
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
2 participants
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.
Bug Fixes
The base image installs the packages that load its Unicode fonts.
Common.listnamed the fonts -lm,lm-math,noto,noto-emoji,notomath,libertinus-fonts,libertinus-otf- but none of the machinery that selects them, so the image obtained it at run time through[MPM]AutoInstall=1, against a package database a container never refreshes. Six packages are installed when the image is built now:unicode-mathandnewunicodechar- required bypytooling.styitself.fontspec- carries\setmainfont,\setsansfontand\setmonofont, and is whatunicode-mathbuilds on.luaotfloadandlualibs- LuaTeX's OpenType font loader and the Lua libraries it loads at startup.luatex85- required by Sphinx's LaTeX output for LuaTeX >= 0.85.A Sphinx PDF build in
pytooling/miktex:sphinxfailed onluaotfloadandluatex85with "module 'luaotfload-main' not found" and "Sphinx requires luatex85.sty".l3backendwas removed from MiKTeX's repository and is replaced byl3kernel. Image builds failed inmiktex packages installwith "Sorry, but: The requested package is unknown." - naming neither the package nor the file - but only on the mirrors that already carried the current package database. Of the entries inCommon.listit was the only one the database no longer knows;l3packagesis unchanged.Known Issues
ci-*tags used while testing accumulate on Docker Hub, one pair per push, and nothing removes them. Promoting doesn't orphan them - the official tag names the same manifest - but the tag list grows.GitHub Pipeline
ci-<short sha>, and a newPublishjob movesdev,releaseandlatestonto the tested image withdocker buildx imagetools create- the manifest is copied inside the registry, so the official tag and the tested tag share a digest. It needs every checking job, and runs only on thedevbranch, a release commit or a release tag, so a feature branch no longer replaces the official tags.TriggerTaggedReleaseandReleasePageneed it too, so a release is neither tagged nor announced when its images didn't reach the registry.Docker.buildx.shrecognized build errors but never counted them, so it always exited0, and both build steps piped into it without-o pipefail. A failed build surfaced one step later asNo such image: <image>, naming the wrong step.pyTooling/Actionsmove from@r7to@r8.TagReleaseCommit.ymlis identical in both lines; inPrepareJob.ymlandPublishReleaseNotes.ymlthe@r7version compared a literal string when checking the merge commit's second parent, so that guard never fired - the step that finds the release pull-request whose description becomes these notes.actions/setup-pythonmoves from@v6to@v7, andsphinxcontrib-mermaidin the Sphinx example from~= 2.0to~= 2.1.Related Issues and Pull-Requests