The crates.io installation test event triggers are not optimal

[EliahKagan]

The ci.yml workflow primarily runs when commits are pushed to main, and in pull requests. It does not run on a schedule, nor following publishing.

cargo-smart-release/.github/workflows/ci.yml

Lines 6 to 13 in 49e50f7

	on:
	pull_request:
	push:
	branches:
	- main
	- 'run-ci/**'
	- '**/run-ci/**'
	workflow_dispatch:

This makes total sense for most of what it is used for, and I do not advocate that it be changed. However, it is surprising to test installation from crates.io on these triggers:

cargo-smart-release/.github/workflows/ci.yml

Lines 54 to 64 in 49e50f7

	installation:
	name: Installation
	strategy:
	matrix:
	os: ["ubuntu-latest", "windows-latest"]
	rust: ["stable"]
	continue-on-error: ${{ matrix.rust != 'stable' }}
	runs-on: ${{ matrix.os }}
	steps:
	- name: "Installation from crates.io: cargo-smart-release"
	run: cargo install --debug --force cargo-smart-release

These may not be the best events to run that check on, since opening and updating pull requests, or integrating changes into main (or, more broadly, pushing to any branch) do not change anything that would cause installation from crates.io to stop (or start) working.

As it stands, this does provide value beyond not having such a job. Problems that affect both crates.io installations of the latest published version of cargo-smart-release and the sometimes newer code as it is being worked on this repository will be caught. Very recently, in #55, this caught that installing cargo-smart-release from source without --locked or --frozen is recently broken on Windows, due to vorner/signal-hook#173. (See also GitoxideLabs/gitoxide#1959.)

But I recommend the check be changed to run after publishing, or on a schedule, or both. This can be done easily by moving to a different, possibly newly created, workflow. The question is how and when it should run.

This seems analogous to GitoxideLabs/gitoxide#1553 (which was fixed in GitoxideLabs/gitoxide#1555).

[Byron]

Thanks a lot for bringing this up!

Changing the check to run post-publish seems to be a good basis, along with periodic runs for good measure (after all, this repository usually is quite inactive).

[EliahKagan]

When a new release of cargo-smart-release is published, is the crate uploaded to crates.io before the release on GitHub is published, or after?

[Byron]

As CSR publishes itself, it will first run cargo publish and then perform the interactions with GitHub. Thus the crate is uploaded before the release on GitHub is happening.

[EliahKagan]

Right, of course! 🤦

[EliahKagan]

This is fixed in #57, which I'll merge once CI passes. After merging it, I'll manually trigger the new workflow to make sure it works (so that's why it shall run--it will not ordinarily run when PRs are integrated).

Edit: It's merged, and the manually triggered run of the new workflow is here. Its Windows job will fail right now, of course, due to vorner/signal-hook#173, as it did in #55 when it was part of ci.yml.