aboutsummaryrefslogtreecommitdiff
path: root/releng
AgeCommit message (Collapse)Author
2024-06-13releng: add sha256 for the manual tarballJade Lovelace
Whoops. Change-Id: Ic6f8cdcb074d679e9b1fc3323c106cc853328dcc
2024-06-13releng: fix upload of multiarch images to forgejoJade Lovelace
Forgejo appears to immediately delete registry content that is overwritten. This means that we are forced to delete our previous workaround of making a temporary tag and use a new, more absurd workaround of making an entire temporary image that we basically only need to create to get its hash. However, on the plus side, the new workaround doesn't create garbage tags to begin with, which means that we don't have to deal with GitHub not implementing the standardized tag delete endpoint and instead only implementing a proprietary one. Upstream-Bug: https://github.com/containers/skopeo/issues/2354 Change-Id: I220e7ce9a17fd230c38882f12c009a166dcc9336
2024-06-13releng: fix git checkingJade Lovelace
Change-Id: I82ddd918311b48e596adb807b81221973113fe7a
2024-06-13releng: fix logging inside interactive xonshJade Lovelace
I don't know when this broke, it seems like it happened since the 24.05 upgrade, so xonsh 0.15. What happened is that xonsh was trying to intercept log output, which explodes if you have the logger survive past one command input. This is, however, impossible to avoid if you are trying to use logging when you import releng from inside xonsh for interactive use! The error below is because the memory handler backing the stdout/stderr of the one command that's just been run was closed after the command completed. Change-Id: I2be642aebf93da9818d08ff8b97c2e72ba5ac581 --- Logging error --- Traceback (most recent call last): File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/logging/__init__.py", line 1113, in emit stream.write(msg + self.terminator) File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/xonsh/base_shell.py", line 183, in write self.mem.write(s) ValueError: I/O operation on closed file. Call stack: File "/nix/store/xgdp1p1gv8ni1awnkzyqasnn6gz5wlvx-xonsh-0.15.1/bin/xonsh", line 8, in <module> sys.exit(main()) File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/xonsh/main.py", line 470, in main sys.exit(main_xonsh(args)) File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/xonsh/main.py", line 514, in main_xonsh shell.shell.cmdloop() File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/xonsh/ptk_shell/shell.py", line 406, in cmd loop line = self.singleline(auto_suggest=auto_suggest) File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/xonsh/ptk_shell/shell.py", line 374, in sin gleline line = self.prompter.prompt(**prompt_args) File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/prompt_toolkit/shortcuts/prompt.py", line 1 026, in prompt return self.app.run( File "/nix/store/34951j60xcsw6zj4v8lsaf491acv0by3-python3-3.11.9-env/lib/python3.11/site-packages/prompt_toolkit/application/application.py", line 1002, in run return asyncio.run(coro) File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/runners.py", line 189, in run with Runner(debug=debug) as runner: File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/runners.py", line 59, in __enter__ self._lazy_init() File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/runners.py", line 137, in _lazy_init self._loop = events.new_event_loop() File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/events.py", line 810, in new_event_loop return get_event_loop_policy().new_event_loop() File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/events.py", line 699, in new_event_loop return self._loop_factory() File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/unix_events.py", line 64, in __init__ super().__init__(selector) File "/nix/store/7hnr99nxrd2aw6lghybqdmkckq60j6l9-python3-3.11.9/lib/python3.11/asyncio/selector_events.py", line 54, in __init__ logger.debug('Using selector: %s', selector.__class__.__name__) Message: 'Using selector: %s' Arguments: ('EpollSelector',) Change-Id: I90959809129aaf96aad4577599031688599ed85e
2024-06-13releng: support multiple systemsJade Lovelace
I guess this is kind of important to being able to "release it". Change-Id: Id6f295d0b4944fa1203783a400a246727dbd94b6
2024-06-12releng: fix docs uploadJade Lovelace
There were two bugs I found: 1. If the build isn't already done in the store, nix-store --realise does not know how to build it. You have to just give it the derivation and I guess it will realise all outputs, which is fine. 2. cp without -T will not overwrite an existing manual directory, creating a path manual/manual. Change-Id: Ibebfd136a266da5330944a985e636ebb776f1909
2024-06-09releng: add prod environment, ready for releaseJade Lovelace
I am *reasonably* confident that this releng infrastructure can actually build a Lix 2.90 and release it successfully. Let's make it possible to do, and add some cute colours to the confirmation message. Change-Id: I85e498b6fb49ffc5e75c0a72c5e45fb1f69030d3
2024-06-09releng: automatically figure out if we should tag latest for dockerJade Lovelace
For example, when releasing from release-2.90, if `main` has a 2.91 tag ancestor, we know that 2.91 was released, so we should *not* tag latest. Change-Id: Ia56b17a2ee03bbec74b7c271c742858c690d450d
2024-06-09releng: support multiarch docker imagesJade Lovelace
If we don't want to have separate registry tags by architecture (EWWWW), we need to be able to build multiarch docker images. This is pretty simple, and just requires making a manifest pointing to each of the component images. I was *going* to just do this API prodding with manifest-tool, but it doesn't support putting metadata on the outer manifest, which is actually kind of a problem because it then doesn't render the metadata on github. So I guess we get a simple little containers API implementation that is 90% auth code. Change-Id: I8bdd118d4cbc13b23224f2fb174b232432686bea
2024-06-09Rewrite docker to be sensible and smallerJade Lovelace
I have checked the image can build things and inspected `diff -ru` compared to the old image. As far as I can tell it is more or less the same besides the later git change. Layers are now 65MB or less, and we aren't against the maxLayers limit for the broken automatic layering to do anything but shove one store path in a layer (which is good behaviour, actually). This uses nix2container which streams images, so the build time is much shorter. I have also taken the opportunity to, in addition to fixing the 400MB single layer (terrible, and what motivated this in the first place), delete about 200MB of closure size inflicted by git vs gitMinimal causing both perl and python to get into closure. People mostly use this thing for CI, so I don't really think you need advanced git operations, and large git can be added at the user side if really motivated. With love for whichever container developer somewhat ironically assumed that one would not run skopeo in a minimal container that doesn't have a /var/tmp. Fixes: https://git.lix.systems/lix-project/lix/issues/378 Change-Id: Icc3aa20e64446276716fbbb87535fd5b50628010
2024-06-09Implement docker upload in the releng toolsJade Lovelace
This uses skopeo to not think about docker daemons. I, however, noticed that the docker image we had would have totally terrible cache hits, so I rewrote it. Fixes: https://git.lix.systems/lix-project/lix/issues/252 Change-Id: I3c5b6c1f3ba0b9dfcac212b2148f390e0cd542b7
2024-06-06releng: support pushing the manual to docs alsoJade Lovelace
Change-Id: Ifd0b51425ee4955e0230fb2804a6f54ef0fe16e9
2024-06-06Put into place initial release engineeringJade Lovelace
This can release x86_64-linux binaries to staging, with ephemeral keys. I think it's good enough to review at least at this point, so we don't keep adding more stuff to it to make it harder to review. Change-Id: Ie95e8f35d1252f5d014e819566f170b30eda152e