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

support x.y-nightly channel to allow testing nightlies on release branches #1145

Merged
merged 1 commit into from
Jan 22, 2025

Conversation

KristofferC
Copy link
Member

Think I finally managed to make a PR from my fork...

.to_string();
let mut arch = parts.next().expect("Failed to parse channel name.");

// Check for the case where name is given as "x.y-latest-...", in which case
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure this is the most elegant way to do this.

@LilithHafner
Copy link
Member

I agree that this is a good feature to have.

If we want to support the master branch and the release-x.y branch, perhaps we should support all branches? The channel nightly[-{BRANCH}] could refer to whatever is the most recent build on {BRANCH} (with the default being the default branch). This would make the branch name here nightly-release-x.y instead of x.y-nightly.

@davidanthoff
Copy link
Collaborator

@LilithHafner I like the idea! @KristofferC maybe just change the PR for now to use nightly-release-x.y but not implement the full general thing for now, i.e. that could come in a future PR? But really up to you.

Otherwise it looks good to me! That is the nice thing about Rust: if it compiles, it often is done ;)

@KristofferC
Copy link
Member Author

I prefer having it like this to have it consistent with e.g. the syntax in Github Actions. I don't think we make nightlies for other than the release branches.

Copy link
Collaborator

@davidanthoff davidanthoff left a comment

Choose a reason for hiding this comment

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

Ok, I have to admit, I don't really care :) From my end this can merge either way. I also don't consider these kind of things part of any "public api" of Juliaup, so we can also change down the road.

Maybe we wait for a few more days if anyone else feels strongly about this, and then merge?

@davidanthoff davidanthoff merged commit 51a190c into JuliaLang:main Jan 22, 2025
25 checks passed
@KristofferC KristofferC deleted the kc/nightly_release branch January 24, 2025 15:26
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.

3 participants