mirrors/arti.git/.gitlab-ci.yml, branch arti-v1.2.5 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.5 2024-06-26T11:52:31Z Enable the build-repro CI job in MR jobs 2024-06-26T11:52:31Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-06-26T11:52:31Z urn:sha1:9ccf0ff08ee8818778cf5d44c04f531b42a2a25e Hopefully this will not be too slow. Fixes #1472. Revert "Disable macos build tests" 2024-06-26T11:52:15Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-06-26T11:47:38Z urn:sha1:900bcc0e0001aa6ef728132357ea35961a2f7ec3 This reverts commit a6801c10584558316ff38f354167812d0c697549. Merge branch 'no-osxcross' into 'main' 2024-06-25T12:32:26Z gabi-250 gabi@torproject.org 2024-06-25T12:32:26Z urn:sha1:54efe0066cd0dddf96c06adfc72cd2f05a372d15 Disable macos build tests See merge request tpo/core/arti!2226 Disable macos build tests 2024-06-25T11:46:30Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-06-25T11:46:30Z urn:sha1:a6801c10584558316ff38f354167812d0c697549 Turn crate ownership discrepancies into a warning 2024-06-24T15:22:19Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-06-24T15:22:19Z urn:sha1:f2f983816a774bedcfa4b3d4412b190499844d45 Ideally we'd tolerate situations with unaccepted ownership requests, but that information doesn't seem to be public. Check crate ownership in CI, but only on main 2024-06-24T12:54:56Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-06-12T15:53:20Z urn:sha1:a09e9c5fa536867bdcaa564446b2540be4d47821 I think that the effect of this will be as follows: * MR branches will never run this, so when the crate ownership is wrong, development can continue. * When a new crate is first published, it will transition from "ignored" to "complaining". This will happen on the first CI run on main after "cargo publish" is run. But it *won't* happen on the CI run on the publication tag. The intent is that we discover a failure to `git add` while the release technician who published the new crate is still around. CI: Bail if unexpectedly using a non-amd64 container 2024-06-18T14:30:09Z Jim Newsome jnewsome@torproject.org 2024-06-17T18:41:05Z urn:sha1:9ec5fabb2c8fb22e4bc7e4cc73c361bdef227bb8 cf https://gitlab.torproject.org/tpo/tpa/team/-/issues/41621, it's possible to unexpectedly run on a container for a different architecture than the one requested. This can result in subtle and difficult to debug issues, e.g. when unexpectedly running in the i386 variant of a container instead of the expected amd64 variant. CI: use single-arch docker images where available 2024-06-17T19:04:54Z Jim Newsome jnewsome@torproject.org 2024-06-17T18:44:53Z urn:sha1:0dd099866b10f96ebe5388a686f7d5f73fb8e6d9 Images with multi-arch manifests suffer from subtle caching issues that can result in running an image with a different arch than intended. See https://gitlab.torproject.org/tpo/tpa/team/-/issues/41621. We can avoid this issue by using single-arch manifests where available. shadow test: bump shadow version to 3.2 2024-06-08T17:18:23Z Jim Newsome jnewsome@torproject.org 2024-06-08T17:18:23Z urn:sha1:79b07127a159275507f1b0149a826b0ee7cb25b7 This includes a fix for a (rare) panic-causing race condition, and misc other additions and improvements. mypy: Enable strict mode 2024-05-28T14:36:50Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-05-28T14:36:04Z urn:sha1:399af51655d117983b7fb82b1739bf0a9288cec1 Consultation with a nearby Python expert, on another topic, revealed that without --strict, mypy turns most of its stuff off by default. Sadly (?) this bureaucracy didn't find any bugs.