What decides between stable and nightly toolchains in release.yml?

[EliahKagan]

The release workflow uses a stable toolchain for some platforms and a nightly toolchain for others. (It does not use a beta toolchain for any.) Why is this, and should it be preserved?

I would ordinarily think the stable toolchain should be used except when there is a specific reason to use another, and also that reasons to use another would tend to relate to bugs and missing features, such that uses of nightly could change to stable eventually. But they have been this way for a long time.

The toolchain is determined by the rust matrix variable:

https://github.com/Byron/gitoxide/blob/29898e3010bd3332418c683f2ac96aff5c8e72fa/.github/workflows/release.yml#L89-L112

Is this intentional, or left over from the past such that, assuming everything still builds, they could all be changed to stable?

It had occurred to me that maybe this was related to the three-tier support status for Rust toolchains. But that doesn't seem to be the case.

I imagine that, when adding new targets, some may require a beta or even nightly build. I figured I would inquire about the current situation before that.

[Byron]

Thanks for bringing this up.

Is this intentional, or left over from the past such that, assuming everything still builds, they could all be changed to stable?

I think I copied it mindlessly and made myself believe it's good to use nightly from time to time.
However, now I think it's best to use stable and mitigate the risk of a release build being broken by nightly.

Let's use stable everywhere, even though I think it's good to have this in a global variable somewhere so it's made explicit at least in one spot of the workflow file.

[EliahKagan]

even though I think it's good to have this in a global variable somewhere so it's made explicit at least in one spot of the workflow file

I think this may be tricky to do in a way that is elegant and clear, because I don't think the values of CI matrix variables can be formed from other CI matrix variables or from environment variables. They can of course be specified in only one place when not overridden, which ordinarily would be a perfect way to do it. But the issue is that while rust is currently always set to stable or latest (and would thus be set to stable) for all but one job, for one job it is set to nightly-x86_64-gnu:

https://github.com/Byron/gitoxide/blob/0b2829712be53846c830dbb175da2beaf00e7c76/.github/workflows/release.yml#L104-L106

It should actually work to set it to stable there and do it as a cross-compilation. (I've done this before and it worked, including when experimenting with this workflow for an unrelated reason.) But I think there is a benefit to having something that verifies and clearly demonstrates that we really can build on Windows with the MinGW tools, and only with the MSVC tools as are used in all the other builds and in most testing.

But all the latest can probably become stable and all the stable, including those that had been latest, can be removed from their job-specific items and made into an item that applies to all jobs other than those (i.e. other than the one) whose items have their own rust key:

- rust: stable

Then the item shown above would change like this, still manually reflecting which channel is used:

 - target: x86_64-pc-windows-gnu
   os: windows-latest
-  rust: nightly-x86_64-gnu
+  rust: stable-x86_64-gnu

But the others would not have to specify it at all. They would all change in a manner analogous to this, and use the default value of rust: stable:

 - target: x86_64-pc-windows-msvc 
   os: windows-latest 
-  rust: nightly 

I'll see if I can figure out anything better. In particular, there are ways to do this that don't involve stable appearing anywhere, by itself or as a substring, in any matrix variable's value, and maybe one of those ways will be nicer. But if I don't find something better than the above, I'll do that. Please let me know if you have any objections, or if there are others ways you think I should consider.

[Byron]

That does sound good already, it's not a hard requirement, and I trust that you will optimize for maintainable code here. I think my comment was geared towards that, without thinking too much about it.

[EliahKagan]

Yes, this seems the most maintainable, because it can always be changed, in any way and making any combination of targets use beta or nightly instead of stable, by overriding them in their own items. Furthermore, having one of them overridden in its own item like this a benefit, since it shows the way for how to do it with others if ever needed.

All the stable builds are able to complete. You can expect a PR very soon. 😄

Edit: I've opened #1513.