Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor bounds definition. #325

Merged
merged 4 commits into from
Jun 18, 2024
Merged

Refactor bounds definition. #325

merged 4 commits into from
Jun 18, 2024

Conversation

ehuss
Copy link
Collaborator

@ehuss ehuss commented Mar 5, 2024

This is a refactoring of the bounds definitions in hopes to make the code easier to follow. I've struggled following it in the existing code because there are several mutations of Opts::start and Opts::end, and the logic for interpreting the bounds was scattered in several places.

A general overview of the change:

  • Moved the bounds code to a separate module to try to clean things up.
  • Added a Bounds enum to represent the start and end boundaries. All code that accessed the start and end values directly now looks at Config::bounds.
  • All the interpretation of --start and --end happens in Bounds::from_args in a single match.
  • Fixed a small bug where it would panic with --by-commit and no --start (it now shows an error).
  • Added some UI tests for the various simple error cases.

This also fixes a bug I somehow run into several times. During the time between midnight UTC and whenever the nightlies are published, cbr will fail if you don't specify an --end. This updates it to fetch the manifest from the network to determine the date of the latest nightly (find_latest_nightly) instead of assuming the current date. This requires pulling in toml to parse the manifest.

Fixes #247

@ehuss ehuss requested a review from oli-obk March 23, 2024 15:26
@ehuss
Copy link
Collaborator Author

ehuss commented May 14, 2024

@Mark-Simulacrum Is this something you would be able to review?

/// date where the regression does not occur.
SearchNightlyBackwards { end: GitDate },
/// Search between two commits.
Commits { start: String, end: String },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, these aren't actually commits -- or at least indirectly so. E.g., origin/master is valid. Maybe we can note that in the comment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! So there was only ever one case where it wasn't a SHA, and that was the origin/master case (when --end was not specified). This was later converted to a SHA. To keep things simple, I shifted the conversion earlier to when the Bounds is created so that the rest of the code can safely assume both values are a SHA.

The SHAs can still be shortened, and that can still be a source of bugs, but for the most part it works. That seems like something that could be further improved in the future to make it more robust.

let date = args
.access
.repo()
.bound_to_date(Bound::Commit(tag.clone()))?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels wrong to me. If we're looking up (say) 1.68.0, we presumably need something here to say that we want the stable release as of that date or otherwise go from the stable release to the nightly date range it "points" at?

Otherwise we're missing ~6 weeks here, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RustRepositoryAccessor::commit function returns the merge base with the master branch. So it essentially looks for the point where the given tag branched off the master branch. It does not return the commit associated with that tag.

That means it does not include any fixes merged to the beta branch, but should provide a close approximation of what the equivalent nightly was.

(This particular code is unchanged from the original, and has been working sufficiently well for me.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I missed that aspect. Sounds good to me.

src/bounds.rs Outdated

/// Returns the date of the latest nightly (fetched from the network).
fn find_latest_nightly() -> anyhow::Result<GitDate> {
let url = format!("{NIGHTLY_SERVER}/channel-rust-nightly.toml");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://static.rust-lang.org/dist/channel-rust-nightly-date.txt maybe works? Not sure if it's uploaded late enough in the process...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that's better! I had forgotten about that.

From what I can tell, it looks like it should work, so I went ahead and switched to the txt file. From what I can see in promote-release, the last step it takes involves copying the manifests, including this txt file, and that happens after the archives have been uploaded.

ehuss added 4 commits June 17, 2024 14:43
There was only ever one case of it containing a non-hash, and that was
when `--start` was a hash, and `--end` was not specified. In that case,
it was "origin/master", and then converted to a hash later on. To
simplify things, this converts `origin/master` to master's actual commit
early when the `Bounds` is created.
This uses the text file to get the nightly date, which is faster and
easier, and doesn't require toml parsing.
@ehuss ehuss merged commit 3f16a92 into rust-lang:master Jun 18, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automatic end-date calculation fails during promotion window
2 participants