-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
GH-45961: [Release][Docs] Upload generated docs to GitHub Releases not apache.jfrog.io #45963
Conversation
|
…ses not apache.jfrog.io We want to stop using apache.jfrog.io. See also: apache#40760 Our generated docs are only for publishing. We publish them to https://arrow.apache.org/docs/ . So we don't need any migration path for users.
a62c717
to
533973f
Compare
Rebased. I'll merge in a few days if nobody objects this. |
-0 I think artifacts would be a more appropriate storage for this and are easily manipulated using |
By this PR? Or by all related PRs such as #45962 and #45964? This PR adds 3 files: All related PRs: 180:
FYI: #45470 adds more wheels.
The "people" refers Python users, right? In general, Python users use PyPI not GitHub Release.
If we use GitHub Actions workflow artifacts, people who verify an RC need their GitHub token to download artifacts from GitHub Actions workflow artifacts. BTW, we need to use multiple
It's an option but it's a bit risky. Building docs in a workflow in arrow-site may be failed after a vote... |
Do we actually need to upload the docs somewhere? I had no idea we were doing this. Are people downloading them? |
Previously, the docs were generated after a release vote. But it sometimes failed. So, we changed to generate the docs in release process, keep it and upload it to apache/arrow-site after a release vote. It's not for users. It's just for a stable release process. BTW, is it strange that we use GitHub Release for artifacts for a release but not for users? |
Yes, I'd say it's a little unconventional. We have just been doing all kinds of funky stuff with it in crossbow^^ |
Hmm. I want to simplify our release process. If we use limited places for artifacts, we can simplify our release process. If we prefer GitHub Actions workflow artifacts to unconventional (but I don't think so...) GitHub Release usage, I'll re-implement this. But it'll spread artifacts to one more place.
I agree with you. |
Oh I guess if we already have 170+ files it doesn't really matter ^^, let's test it with 20.0 I'll merge it later |
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit ca311c1. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 31 possible false positives for unstable benchmarks that are known to sometimes produce them. |
Rationale for this change
We want to stop using apache.jfrog.io. See also: #40760
What changes are included in this PR?
Upload generated docs to GitHub Release instead of apache.jfrog.io.
Our generated docs are only for publishing. We publish them to
https://arrow.apache.org/docs/ . So we don't need any migration path
for users.
Are these changes tested?
No. I want to try this in the next release.
Are there any user-facing changes?
No.