CI: Fix nightly lint error & fix rust nightly version

[Xynnn007]

1. Fixes nightly lint error
2. Follow the discussion from @portersrc , I fix the version of rust nightly compiler in GHA to avoid unexpected CI errors everytime new rust nightly version is released.

[mkulke]

there is a case for testing against nightly: you will pick up changes early that will propagate to stable in later releases, like the last nightly breakage that we've seen.

[mkulke]

why fixing nightly to an (arbitrary?) date, would that give us any additional confidence?

[portersrc]

I made a few comments in confidential-containers/confidential-containers#193

I would just drop nightly @mkulke. rust-nightly doesn't necessarily hit stable (if I understand correctly), and even rust-beta is overhead we don't need until we're ready to bump to a stable version.

But FWIW, I'd say @Xynnn007's pinned nightly is better than nightly, b/c of the reasons he stated. Arbitrary date is fine.

[mkulke]

I made a few comments in confidential-containers/confidential-containers#193

I would just drop nightly @mkulke. rust-nightly doesn't necessarily hit stable (if I understand correctly), and even rust-beta is overhead we don't need until we're ready to bump to a stable version.

But FWIW, I'd say @Xynnn007's pinned nightly is better than nightly, b/c of the reasons he stated. Arbitrary date is fine.

no, not everything that hits nightly will end up in stable, but more specifically: if something doesn't compile in nightly today it's likely that eventually it will also break in stable, because the original behaviour was based on a bug. not sure if this is a hard rule, but that has been my experience. So in this respect nightly can be a good indicator of upcoming changes that need be dealt with.

that said, I wouldn't mind dropping beta and nightly (I don't see the point in testing against some revision of nightly, but I might be missing something) from the matrix. I don't think the project is affected too much by those changes.

[Xynnn007]

@mkulke Right. Nightly test will tell us the potential error asap. however, there might be cases where indirect dependency breaks, which will block the daily development. At the same time, if we update nightly version periodically, we also might need to handle a bunch of errors one time.

This is a every-day-a-little vs a-batch-one-time problem. I am okay with both tbh temporarily as they both has pros and cons. If finally it is decided not to fix nightly version, I will drop the commit in this PR.

[mkulke]

yeah, this is mostly bikeshedding, so I while I have opinions, it probably does not matter 😅 but I'm intellectually curious: what good would pinning a nightly version does vs just dropping nightly from the matrix?

would there be a checkbox item on the release list that says "bump the nightly version and fix all potential errors?"

[fitzthum]

Personally I think I lean more towards dropping nightly. We don't make any claims about supporting it. I don't see much benefit in testing with it.

[Xynnn007]

good. So it seem clear that we do not need to check against nightly and beta anymore. Let me just delete them in this PR : )

[wainersm]

LGTM @Xynnn007 !

[portersrc]

Thanks @Xynnn007 for fielding this. Maybe catch kbs-e2e and kbs-docker-e2e in this PR, as well.