Does release.yml not run when v* tags are pushed?

[EliahKagan]

I've noticed that all runs of the release workflow seems to have been manually triggered, i.e. through the workflow_dispatch event. It also seems like creating the v* tag for gitoxide releases does not trigger it. For example, as of this writing, it has not yet run for v0.43.0, even though the tag and the GitHub release (with no added assets yet) exist.

Is the tag being created in a way that is not considered a push event? I think even when a tag is created through the UI, it is a push event, but perhaps implicit tag creation due to the creation of a GitHub release does not do that--I am not sure. I believe cargo-smart-release creates and pushes the tag, but that it creates the release first, at least in draft form. If the tag is implicitly created in connection with the GitHub release before any tag is explicitly created or before a local tag is pushed, then maybe that could cause this? I don't know.

Also, is this general situation, where the workflow is only run manually, intentional? Or is the workflow being manually triggered as a workaround for the push trigger not working?

[Byron]

Unfortunately, these don't run even though they should.

Is the tag being created in a way that is not considered a push event? I think even when a tag is created through the UI, it is a push event, but perhaps implicit tag creation due to the creation of a GitHub release does not do that--I am not sure.

That's a good point, the regex should obviously match the tag name (and did before), which may indicate that the event is either not registered, or it's not the right event.
As all that CSR does is to push a bunch of tags, I don't think it will be an issue with the even either.

But here comes a hot take: I know it just stopped working without obvious cause, or one could say, over time. What changes with time? The amount of tags, as there are more and more crates.
This would be something testable as one could release all crates up to gix, and later follow with the gitoxide release.
My feeling is that there is some kind of rate-limiting at work.
Something else that might have happened is the fact that these tags are pushed while pointing to unmerged commits. Maybe this is why they are ignored?

On another note: Can it be that there is no CI job anymore that would be installing from crates.io? I think the current release may actually be broken now (and I am investigating if that's the case for everyone).

crates-index-diff-rs ( main) [$]
❯ cargo build
   Compiling gix-odb v0.68.0
   Compiling gix-diff v0.51.0
   Compiling gix-submodule v0.18.0
error[E0277]: the trait bound `impl gix_object::FindObjectOrHeader: gix_worktree::gix_object::Find` is not satisfied
   --> /Users/byron/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/gix-diff-0.51.0/src/blob/platform.rs:666:44
    |
666 |                 .at_entry(rela_path, None, objects)
    |                                            ^^^^^^^ the trait `gix_worktree::gix_object::Find` is not implemented for `impl gix_object::FindObjectOrHeader`
    |
    = note: required for the cast from `&impl gix_object::FindObjectOrHeader` to `&dyn gix_worktree::gix_object::Find`
help: consider restricting opaque type `impl gix_object::FindObjectOrHeader` with trait `Find`
    |
642 |         objects: &impl gix_object::FindObjectOrHeader + gix_worktree::gix_object::Find,
    |                                                       ++++++++++++++++++++++++++++++++

For more information about this error, try `rustc --explain E0277`.
error: could not compile `gix-diff` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

[Byron]

It is breaking the world - will have to yank everything.

[EliahKagan]

What changes with time? The amount of tags, as there are more and more crates.

This makes sense to me. All changes I have made to the release workflow (except maybe minor formatting changes? I'm not sure), I have tested in my fork. In my testing, I have always used the push trigger, and it always worked. But I never tried pushing numerous other tags immediately before the v* tag.

I've observed that, when pushing multiple commits in quick succession, at least when they are pushed to a PR opened on a separate repository, some commits do not trigger CI. (I observed this when using git-push-forward with shorter than the current 10-second gap, in GitPython.) I would not be surprised if something similar happens with tags.

Can it be that there is no CI job anymore that would be installing from crates.io?

My guess is that whatever broke did not keep gitoxide from building, and therefore did not fail those jobs. I only tested on my Windows 10 development machine, so I am not sure if this is true for all platforms, but gitoxide v0.43.0 downloaded from crates.io and built from source without problems, and runs.

Edit: I just checked and the CI jobs for that did run. But it seems we only have them for Windows. (They test several targets, but all are on Windows.) So if the gitoxide crate itself had problems installing but only on non-Windows systems, then neither my own testing nor those checks, even in combination, would reveal that. My guess, however, is that the gitoxide crate itself was okay, somehow.

Something else that might have happened is the fact that these tags are pushed while pointing to unmerged commits. Maybe this is why they are ignored?

Maybe that is a factor that affects the rate limit in some way. But pushing tags that point to commits that are not in the history of the default branch does, in general, trigger the push event. When I test the workflow in my fork, I am almost always testing changes, and accordingly I am pushing a tag that is on an unmerged branch. This has always worked.

So I think the tags being on unmerged commits either has no effect here or the effect is small and not the primary cause.

I think the current release may actually be broken now (and I am investigating if that's the case for everyone).

It's very hard to correctly clean it up… I will keep checking if everything is broken or just some parts, and if so, I will try to repair the broken projects by upgrading them.

Oddly enough, in EliahKagan/cargo-smart-release#12 (which is a test PR for a possible forthcoming change to dependabot.yml in cargo-smart-release), I was curious why Dependabot didn't upgrade all gix-* crates all the way. I still don't know why, but it seemed to get most of the changes in recent gix-* crate releases, while avoiding the problem you just showed. It has test failures, but they seem all to be in areas where the code of cargo-smart-release actually has to be changed to adapt to changes in gix-* crates.

But when I ran cargo update, I saw errors like those you showed. This was the further change, from running cargo update, that produced them.

(The behavior of cargo-smart-release is not important to that. Rather, it is just an example of a package that consumes gix-* crates.)

I don't know if that information will help or not, but I figured I'd mention it.

[Byron]

My guess is that whatever broke did not keep gitoxide from building, and therefore did not fail those jobs. I only tested on my Windows 10 development machine, so I am not sure if this is true for all platforms, but gitoxide v0.43.0 downloaded from crates.io and built from source without problems, and runs.

I see, thanks for investigating. This time, crates-index-diff caught the issue, but only with an hour delay. What's missing is a test that installs a crate or binary that uses gix and is known to be up-to-date. What comes to mind is starship - they were already on the now yanked v0.72 (probably because their builds broke with v0.71), so I think for more release-safety we should also try to install starship as part of the post-release smoke testing. What do you think?

[EliahKagan]

What do you think?

I'm not clear on how that would work.

What's missing is a test that installs a crate or binary that uses gix and is known to be up-to-date.

Why doesn't the current test of whether gitoixde installs do this? The latest version of gitoxde should always depend on the latest gix, right?

What comes to mind is starship - they were already on the now yanked v0.72

What does starship give that we don't get from trying to install the gitoxide crate?

Would we test by installing from the tip of the starship Git repository? Wherever we would install from, what would such a test tell us? Sometimes there are actual breaking changes in gix such that code that uses it has to be adjusted for the changes. Likewise, a breaking bug where no breaking change is indicated would not always be caught if starship doesn't contain code that uses whatever broke. It seems to me that gitoxide itself uses much more of the code in gix-* crates than starship does.

(probably because their builds broke with v0.71)

The upgrade to 0.72.0 was in starship/starship#6699. That doesn't have any comments about a specific reason for upgrading; starship seems to upgrade all dependencies regularly when it is feasible to do so, and that PR was created automatically by Renovate. (I'm not aware of any previous problems either, and I didn't find them in a cursory search. Did they have problems with gix 0.71.0?)

More importantly, I would not expect the version to be bumped in starship soon enough that installing starship in a job in our release.yml, even from the tip of starship's master branch, would use the just-published gix. Even if starship were somehow to use Renovate in such a way that it constantly checks and applies updates immediately, I would still expect that we would test too soon to get just-released gix-* versions, some large fraction of the time.

A more concrete reason for my skepticism is that installation of starship does not appear to have actually been broken. At least on Ubuntu 24.04 LTS with stable-x86_64-unknown-linux-gnu -- installing starship from starship/starship@32c30cb (i.e., between starship/starship#6699 and starship/starship#6700) and passing --locked to ensure that the exact versions in Cargo.lock are used even though some of them, including gix 0.72.0, are yanked -- everything installs just fine:

ubuntu@crow:~$ cargo uninstall starship
    Removing /home/ubuntu/.cargo/bin/starship
ubuntu@crow:~$ cargo install --git https://github.com/starship/starship.git --rev 32c30cb857e69b8544522c06ae282b65e0aaf48f --locked
    Updating git repository `https://github.com/starship/starship.git`
  Installing starship v1.22.1 (https://github.com/starship/starship.git?rev=32c30cb857e69b8544522c06ae282b65e0aaf48f#32c30cb8)
    Updating crates.io index
warning: package `gix v0.72.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-actor v0.35.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-command v0.5.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-commitgraph v0.27.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-config v0.45.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-config-value v0.14.13` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-date v0.10.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-diff v0.52.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-discover v0.40.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-features v0.42.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-fs v0.14.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-glob v0.19.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-hash v0.17.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-index v0.39.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-object v0.49.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-odb v0.69.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-pack v0.59.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-packetline v0.18.5` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-path v0.10.16` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-protocol v0.50.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-quote v0.5.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-ref v0.52.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-refspec v0.30.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-revision v0.34.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-revwalk v0.20.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-sec v0.10.13` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-shallow v0.3.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-transport v0.46.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-traverse v0.46.0` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-url v0.30.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-utils v0.2.1` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
warning: package `gix-validate v0.9.5` in Cargo.lock is yanked in registry `crates-io`, consider running without --locked
   Compiling proc-macro2 v1.0.95
   Compiling unicode-ident v1.0.18
   Compiling libc v0.2.172
   Compiling memchr v2.7.4
   Compiling cfg-if v1.0.0
   Compiling autocfg v1.4.0
   Compiling crossbeam-utils v0.8.21
   Compiling serde v1.0.219
   Compiling thiserror v2.0.12
   Compiling once_cell v1.21.3
   Compiling fastrand v2.3.0
   Compiling regex-syntax v0.8.5
   Compiling stable_deref_trait v1.2.0
   Compiling smallvec v1.15.0
   Compiling version_check v0.9.5
   Compiling tinyvec_macros v0.1.1
   Compiling parking_lot_core v0.9.10
   Compiling tinyvec v1.9.0
   Compiling gix-trace v0.1.12
   Compiling log v0.4.27
   Compiling bitflags v2.9.0
   Compiling typenum v1.18.0
   Compiling scopeguard v1.2.0
   Compiling home v0.5.11
   Compiling zlib-rs v0.5.0
   Compiling crc32fast v1.4.2
   Compiling same-file v1.0.6
   Compiling heapless v0.8.0
   Compiling generic-array v0.14.7
   Compiling byteorder v1.5.0
   Compiling walkdir v2.5.0
   Compiling itoa v1.0.15
   Compiling lock_api v0.4.12
   Compiling ahash v0.8.11
   Compiling cpufeatures v0.2.17
   Compiling zerocopy v0.7.35
   Compiling allocator-api2 v0.2.21
   Compiling hash32 v0.3.1
   Compiling pin-project-lite v0.2.16
   Compiling jiff v0.2.10
   Compiling getrandom v0.3.2
   Compiling rustix v1.0.5
   Compiling quote v1.0.40
   Compiling aho-corasick v1.1.3
   Compiling crossbeam-channel v0.5.15
   Compiling winnow v0.7.7
   Compiling syn v2.0.100
   Compiling parking v2.2.1
   Compiling linux-raw-sys v0.9.4
   Compiling concurrent-queue v2.5.0
   Compiling hashbrown v0.14.5
   Compiling litemap v0.7.5
   Compiling icu_locid_transform_data v1.5.1
   Compiling unicode-normalization v0.1.24
   Compiling writeable v0.5.5
   Compiling futures-core v0.3.31
   Compiling event-listener v5.4.0
   Compiling icu_properties_data v1.5.1
   Compiling equivalent v1.0.2
   Compiling hashbrown v0.15.2
   Compiling event-listener-strategy v0.5.4
   Compiling icu_normalizer_data v1.5.1
   Compiling futures-io v0.3.31
   Compiling gix-utils v0.2.1
   Compiling toml_datetime v0.6.9
   Compiling block-buffer v0.10.4
   Compiling crypto-common v0.1.6
   Compiling digest v0.10.7
   Compiling static_assertions v1.1.0
   Compiling futures-lite v2.6.0
   Compiling slab v0.4.9
   Compiling indexmap v2.9.0
   Compiling sha1 v0.10.6
   Compiling utf8_iter v1.0.4
   Compiling crunchy v0.2.3
   Compiling regex-automata v0.4.9
   Compiling sha1-checked v0.10.0
   Compiling memmap2 v0.9.5
   Compiling parking_lot v0.12.3
   Compiling utf16_iter v1.0.5
   Compiling rustix v0.38.44
   Compiling write16 v1.0.0
   Compiling tracing-core v0.1.33
   Compiling prodash v29.0.2
   Compiling unicode-xid v0.2.6
   Compiling tiny-keccak v2.0.2
   Compiling libz-rs-sys v0.5.0
   Compiling linux-raw-sys v0.4.15
   Compiling flate2 v1.1.1
   Compiling const_format_proc_macros v0.2.34
   Compiling toml_edit v0.22.25
   Compiling async-lock v3.4.0
   Compiling foldhash v0.1.5
   Compiling async-task v4.7.1
   Compiling percent-encoding v2.3.1
   Compiling utf8parse v0.2.2
   Compiling anstyle-parse v0.2.6
   Compiling form_urlencoded v1.2.1
   Compiling getrandom v0.2.15
   Compiling gix-sec v0.10.13
   Compiling async-channel v2.3.1
   Compiling num-traits v0.2.19
   Compiling memoffset v0.9.1
   Compiling tempfile v3.19.1
   Compiling atomic-waker v1.1.2
   Compiling colorchoice v1.0.3
   Compiling powerfmt v0.2.0
   Compiling anstyle v1.0.10
   Compiling tz-rs v0.7.0
   Compiling zerocopy v0.8.24
   Compiling cfg_aliases v0.2.1
   Compiling is_terminal_polyfill v1.70.1
   Compiling anstyle-query v1.1.2
   Compiling endi v1.1.0
   Compiling anstream v0.6.18
   Compiling nix v0.29.0
   Compiling deranged v0.4.0
   Compiling piper v0.2.4
   Compiling tzdb_data v0.2.2
   Compiling const-random-macro v0.1.16
   Compiling signal-hook-registry v1.4.5
   Compiling clap_lex v0.7.4
   Compiling unicode-width v0.2.0
   Compiling iana-time-zone v0.1.63
   Compiling num-conv v0.1.0
   Compiling unicase v2.8.1
   Compiling time-core v0.1.4
   Compiling strsim v0.11.1
   Compiling heck v0.5.0
   Compiling num_threads v0.1.7
   Compiling ucd-trie v0.1.7
   Compiling shell-words v1.1.0
   Compiling arrayvec v0.7.6
   Compiling either v1.15.0
   Compiling proc-macro-crate v3.3.0
   Compiling clap_builder v4.5.37
   Compiling time v0.3.41
   Compiling const-random v0.1.18
   Compiling uluru v3.1.0
   Compiling blocking v1.6.1
   Compiling const_format v0.2.34
   Compiling crossbeam-epoch v0.9.18
   Compiling synstructure v0.13.1
   Compiling bstr v1.12.0
   Compiling serde_json v1.0.140
   Compiling is_debug v1.1.0
   Compiling clru v0.6.2
   Compiling rayon-core v1.12.1
   Compiling crossbeam-deque v0.8.6
   Compiling async-fs v2.1.2
   Compiling dlv-list v0.5.2
   Compiling async-executor v1.13.1
   Compiling rand_core v0.9.3
   Compiling tzdb v0.7.2
   Compiling filetime v0.2.25
   Compiling xdg-home v1.3.0
   Compiling async-broadcast v0.7.2
   Compiling ordered-stream v0.2.0
   Compiling is-docker v0.2.0
   Compiling unicode-bom v2.0.3
   Compiling dunce v1.0.5
   Compiling ryu v1.0.20
   Compiling minimal-lexical v0.2.1
   Compiling toml_write v0.1.0
   Compiling ppv-lite86 v0.2.21
   Compiling starship-battery v0.10.1
   Compiling hex v0.4.3
   Compiling semver v1.0.26
   Compiling arc-swap v1.7.1
   Compiling process_control v5.0.0
   Compiling option-ext v0.2.0
   Compiling fnv v1.0.7
   Compiling serde_derive v1.0.219
   Compiling thiserror-impl v2.0.12
   Compiling zerofrom-derive v0.1.6
   Compiling yoke-derive v0.7.5
   Compiling zerovec-derive v0.10.3
   Compiling displaydoc v0.2.5
   Compiling icu_provider_macros v1.5.0
   Compiling enumflags2_derive v0.7.11
   Compiling tracing-attributes v0.1.28
   Compiling clap_derive v4.5.32
   Compiling shadow-rs v1.1.1
   Compiling async-trait v0.1.88
   Compiling maybe-async v0.2.10
   Compiling serde_repr v0.1.20
   Compiling gix-validate v0.9.5
   Compiling gix-date v0.10.0
   Compiling zerofrom v0.1.6
   Compiling gix-path v0.10.16
   Compiling yoke v0.7.5
   Compiling gix-actor v0.35.0
   Compiling zerovec v0.10.4
   Compiling gix-chunk v0.4.11
   Compiling gix-features v0.42.0
   Compiling gix-quote v0.5.1
   Compiling gix-config-value v0.14.13
   Compiling pest v2.8.0
   Compiling tracing v0.1.41
   Compiling gix-command v0.5.1
   Compiling gix-fs v0.14.1
   Compiling polling v3.7.4
   Compiling gix-glob v0.19.1
   Compiling gix-tempfile v17.0.0
   Compiling async-io v2.4.0
   Compiling gix-bitmap v0.2.14
   Compiling starship v1.22.1 (/home/ubuntu/.cargo/git/checkouts/starship-3f5126c1a38c723e/32c30cb)
   Compiling rand_chacha v0.9.0
   Compiling gix-lock v17.0.0
   Compiling tinystr v0.7.6
   Compiling icu_collections v1.5.0
   Compiling clap v4.5.37
   Compiling clap_complete v4.5.47
   Compiling dirs-sys v0.5.0
   Compiling icu_locid v1.5.0
   Compiling nom v7.1.3
   Compiling async-signal v0.2.10
   Compiling is-wsl v0.4.0
   Compiling async-process v2.3.0
   Compiling ordered-multimap v0.7.3
   Compiling uom v0.36.0
   Compiling pest_meta v2.8.0
   Compiling itertools v0.14.0
   Compiling hashlink v0.10.0
   Compiling icu_provider v1.5.0
   Compiling errno v0.2.8
   Compiling nom v8.0.0
   Compiling encoding_rs v0.8.35
   Compiling pest_generator v2.8.0
   Compiling icu_locid_transform v1.5.0
   Compiling lazy_static v1.5.0
   Compiling trim-in-place v0.1.7
   Compiling bytesize v1.3.3
   Compiling env_home v0.1.0
   Compiling lazycell v1.3.0
   Compiling pathdiff v0.2.3
   Compiling icu_properties v1.5.1
   Compiling arraydeque v0.5.1
   Compiling open v5.3.2
   Compiling systemstat v0.2.4
   Compiling which v7.0.3
   Compiling pest_derive v2.8.0
   Compiling rust-ini v0.21.1
   Compiling yaml-rust2 v0.10.1
   Compiling guess_host_triple v0.1.4
   Compiling rayon v1.10.0
   Compiling clap_complete_nushell v4.5.5
   Compiling dirs v6.0.0
   Compiling rand v0.9.1
   Compiling zvariant_utils v3.2.0
   Compiling enumflags2 v0.7.11
   Compiling chrono v0.4.40
   Compiling regex v1.11.1
   Compiling faster-hex v0.10.0
   Compiling zvariant_derive v5.4.0
   Compiling gix-hash v0.17.1
   Compiling gix-packetline v0.18.5
   Compiling gix-hashtable v0.8.0
   Compiling icu_normalizer v1.5.0
   Compiling gix-object v0.49.0
   Compiling gix-commitgraph v0.27.1
   Compiling gix-shallow v0.3.1
   Compiling serde_spanned v0.6.8
   Compiling versions v7.0.0
   Compiling os_info v3.10.0
   Compiling terminal_size v0.4.2
   Compiling idna_adapter v1.2.0
   Compiling zvariant v5.4.0
   Compiling idna v1.0.3
   Compiling quick-xml v0.37.4
   Compiling nu-ansi-term v0.50.1
   Compiling unicode-segmentation v1.12.0
   Compiling path-slash v0.2.1
   Compiling url v2.5.4
   Compiling jsonc-parser v0.26.2
   Compiling urlencoding v2.1.3
   Compiling gix-revwalk v0.20.0
   Compiling gix-ref v0.52.0
   Compiling gix-revision v0.34.0
   Compiling gix-traverse v0.46.0
   Compiling gix-url v0.30.1
   Compiling gix-pack v0.59.0
   Compiling gix-diff v0.52.0
   Compiling gix-transport v0.46.1
   Compiling gix-refspec v0.30.0
   Compiling gix-index v0.39.1
   Compiling whoami v1.6.0
   Compiling gix-config v0.45.0
   Compiling gix-protocol v0.50.0
   Compiling gix-discover v0.40.0
   Compiling zbus_names v4.2.0
   Compiling toml v0.8.21
   Compiling gix-odb v0.69.0
   Compiling zbus_macros v5.5.0
   Compiling gix v0.72.0
   Compiling zbus v5.5.0
   Compiling notify-rust v4.11.7
    Finished `release` profile [optimized] target(s) in 3m 11s
  Installing /home/ubuntu/.cargo/bin/starship
   Installed package `starship v1.22.1 (https://github.com/starship/starship.git?rev=32c30cb857e69b8544522c06ae282b65e0aaf48f#32c30cb8)` (executable `starship`)

Edit: Running the same command on Windows 10 with stable-x86_64-pc-windows-msvc likewise succeeds.

In view of all that...

This time, crates-index-diff caught the issue, but only with an hour delay.

...I wonder if this can be leveraged to make something we can put in release.yml that would catch such problems. How did crates-index-diff catch this? Was it by failing to build, as part of building some program that used it? I've looked at the project repo and I can't tell from any changes there or the release announcement what happened.

Edit 2: In case it is of interest, the code and exact (now yanked) versions where I had encountered the problem as mentioned in #1970 (reply in thread) can be seen in EliahKagan/cargo-smart-release#12, specifically in the second commit I pushed there, whose errors can be seen here on CI.

I am guessing and hoping that whatever you observed with crates-index-diff may lead to a better and more reproducible way to catch these. But if not, then maybe something could be adapted from that.

[Byron]

Why doesn't the current test of whether gitoixde installs do this? The latest version of gitoxde should always depend on the latest gix, right?

The goal of such a test would be to find out if a new release breaks the previous release. Installing the latest (just released) release of gitoxide (from my experience) always works (it may only fail if a third-party dependency breaks outside of semver).

Using a downstream program for installation that we know catches up with releases very quickly and that is ubiquitous, like starship, would be a good canary for this kind of problem. Ideally, it's run soon after the release is made, and since tag-triggers don't really work I think such a task would be part of the 'create release binaries' workflow, such that at least an email is generated.

Would we test by installing from the tip of the starship Git repository? Wherever we would install from, what would such a test tell us? Sometimes there are actual breaking changes in gix such that code that uses it has to be adjusted for the changes. Likewise, a breaking bug where no breaking change is indicated would not always be caught if starship doesn't contain code that uses whatever broke. It seems to me that gitoxide itself uses much more of the code in gix-* crates than starship does.

That is true. An alternative would certainly be to have a script that figures out the previous release of gitoxide and tries to install that.

Regarding starship, sorry to have put you on a hunt for what turned out to be a phantom - it was just my assumption that v0.72 broke them, they didn't reach out. So indeed, it's probably better to find another 'canary'.

I am guessing and hoping that whatever you observed with crates-index-diff may lead to a better and more reproducible way to catch these. But if not, then maybe something could be adapted from that.

For context, crates-index-diff runs a cron job to do a stress-test with the latest crates-index, to assure it truly works as it should in the light of current crates-index data.

To sum it up, while we could install crate-index-diff as part of a post-release smoke test to validate the previous release, it might be possible to also install the previous release of gitoxide (Cargo must auto-upgrade all upgradable dependencies which happens as part of the installation, but one could probably also do cargo update + cargo build to achieve the same).