fleshed out "nightly builds" system

[Gankra]

A couple releases ago we shipped an undocumented feature called release-branch:

cargo-dist/cargo-dist/src/config.rs

Lines 245 to 247 in d97fc68

	/// Instead of triggering releases on tags, trigger on pushing to a specific branch
	#[serde(skip_serializing_if = "Option::is_none")]
	pub release_branch: Option<String>,

This feature is for a gitops-style "every push to this branch is a deploy". As part of this we force cargo-dist to select all publishable apps, take the maximum of their versions, and then append -alpha.{timestamp} to that version, and then pretend the all apps have that version:

cargo-dist/cargo-dist/src/announce.rs

Lines 511 to 525 in d97fc68

	/// Modify the version to include a timestamp in the prerelease portion
	fn timestamp_version(version: &mut Version) {
	// FIXME: it would be nice if this was configurable with a template
	// the current template here is `{version}-alpha.{timestamp}`.
	// Although as actually uses this is `{max_version}-alpha.{timestamp}`.
	if version.pre.is_empty() {
	// FIXME?: should we actually unconditionally do this?
	version.pre = semver::Prerelease::new("alpha").unwrap();
	}
	let now = std::time::SystemTime::now();
	let secs = now.duration_since(std::time::UNIX_EPOCH).unwrap().as_secs();
	// FIXME?: use chrono for better format
	version.pre = semver::Prerelease::new(&format!("{}.{}", version.pre, secs)).unwrap();
	}

A lot of this is the machinery you might want for a "nightly release" but there are some potential differences/improvement:

• The cargo packages aren't actually modified to have the given version (so clap-based --version flags won't mention it's a nightly)
  • While in a concrete case this is straight-forward, in the general case things are quite complicated with things like workspace-version-inheritance. I briefly looked into vendoring some code from release-plz but ended up discarding it when i got to the end.
  • If you care about commiting and tagging your nightlies this raises a lot of questions about modifying the tree permanently
• For a "nightly" workflow you might want something more akin to a cron job than "every push"
• As seen in the comments, it would be nice for the version string to be a template

[Dekker1]

This was a feature that I was looking for! When trying it by setting release_branch in Cargo.toml it, however, seems to fully replace the mechanism of releasing based on tags when looking at the newly generated action. For my purpose I'm happy with the currently described mechanisms, but I would still want to also create "final" releases. Am I overlooking a way in which this is still possible, or would additional engineering be required to also allow the normal release mechanism?

[bjeanes]

I am really enjoying cargo-dist but this is one thing I am missing from it.

Some thoughts:

• Before switching to cargo-dist this week, I previously had a GH action which deleted-and-recreated a pre-release GH release tagged unstable and attached builds from HEAD to this. I also build docker images and so pushed to an edge tag.

• The -alpha.{timestamp} approach seems quite nice, but for projects who released named alphas, they would order higher than -alpha.1. Not sure if semver will take issue with non-standard suffix tags like -unstable.{timestamp} or such, but that might be worth considering. Especially for the suggestion of a cron-style job, -nightly.{timestamp} could work well.

• Another naming scheme to consider is similar to how git-describe works, where it suffixes -{n}-{sha}, where n is the number of commits since some base tag.

  Some care needs to be taken for multi-package workspaces to select tags matching the package name. For instance:

  ❯ git describe --long --always --tags
  tokio_modbus-winets-v0.2.1-18-gb3ea30f
  ❯ git describe --long --always --tags --match 'modbus-mqtt*'
  modbus-mqtt-v0.3.0-18-gb3ea30f

• Clarification sought:

  take the maximum of their versions, and then append -alpha.{timestamp} to that version, and then pretend the all apps have that version:

  Does this imply that a workspace with foo-v1.2.3 and bar-v0.3.1 would be built as foo-v1.2.3-alpha.{timestamp} and bar-v1.2.3-alpha.{timestamp}?

  Increasing bar's version drastically seems surprising here, but more importantly v1.2.3-alpha.123 logically sorts lower than v1.2.3 in SemVer (I think?), because it implies an alpha release of v1.2.3.

  I may be misunderstanding, but this is where the git style tagging could work well, perhaps with + instead of - as the separator, as commonly denotes "patches": foo-v1.2.3+g3-deadbeef and bar-v0.3.1+g7-deadbeef (g3 and g7 being different in this example to denote that foo-v1.2.3 and bar-v0.3.1 tags might point to different commits in the history).