Repository navigation
Please consider moving gh-pages to another repository and/or reduce the size of the branch #2048
Description
The clone of https://github.com/junit-team/junit5 takes a lot. It downloads ~500MiB+, and the resulting repository is full of various pdf files.
Here are the top consumers:
hash bytes path
fffea6e6616e 3812203 docs/5.5.1/user-guide/index.pdf
d3f697d9c019 3812203 docs/5.5.0/user-guide/index.pdf
30d099b3af05 3812203 docs/5.5.2/user-guide/index.pdf
6267c2a59eb1 3812011 docs/snapshot/user-guide/index.pdf
...
and so on.
It does impact both regular development experience (as everybody is used to just git clone $url), and it does impact GitHub Actions CI: it takes 1minute for the "checkout action".
Note: GitHub Action could probably be improved to skip gh-pages branch, however, the issue for humans would sill be there.
-
Are PDFs required? Could they be pushed somewhere else? Do all the snapshots need to be stored in the main repository?
-
Could you please consider the use of
noTimestampfor thejavadoc? It will avoid printing the timestamps, thus it would reduce the changes in the html files.
See Use notimestamp for JavaDoc and notimestamp+noversionstamp for GroovyDoc gradle/gradle#8619
Sample:
withType<Javadoc>().configureEach {
(options as StandardJavadocDocletOptions).apply {
noTimestamp.value = true
Activity
vlsi commentedon Oct 7, 2019
Adding fetch-depth: 50 might help (to a degree), however it looks like the current GitHub Actions always fetches all the branches in the repository: actions/checkout#22 :(
AFAIK https://github.com/meetup/express-checkout does not help (it does not understand pull requests)
marcphilipp commentedon Oct 8, 2019
I agree that we should improve the current situation. 🙂
We'll have to be careful not to break existing URLs, i.e. junit.org/junit5/... should continue to work.
Does anyone know what would happen if we moved the
gh_pagesbranch to a newjunit5subdir in https://github.com/junit-team/junit-team.github.io?vlsi commentedon Oct 8, 2019
Just wondering: do you need all the Git history for gh-pages?
What if gh-pages is truncated (e.g. to keep 10 recent commits only)
marcphilipp commentedon Oct 8, 2019
I think that would be ok. Or we could keep the manual commits and squash all others?
marcphilipp commentedon Oct 8, 2019
FWIW we already set
noTimestamp:https://github.com/junit-team/junit5/blob/6f979d6c6c2bc8d61e35debd11499de8920e7b1e/documentation/documentation.gradle.kts#L234
vlsi commentedon Oct 8, 2019
It could make sense. For instance, if the latest commit is automatic, then amend it + force-push-with-lease.
marcphilipp commentedon Nov 21, 2019
I created a script based on one I found on StackOverflow that squashes subsequent commits with the same message. The total number of commits on the
gh-pagesbranch would go down from 3347 to 331.@junit-team/junit-lambda Are you ok with me force-pushing that to
gh-pages? Everyone who previously checked out the branch would have to do a hard reset in their clone/fork.sormuras commentedon Nov 21, 2019
👍
Pruning old or even all versions of committed PDF files would shrink the repository size even further.
16 remaining items
vlsi commentedon Jun 4, 2021
Just in case,
actions/checkoutno longer fetches all branches and tags, so it is fast.stale commentedon Jun 19, 2022
This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.
stale commentedon Jul 11, 2022
This issue has been automatically closed due to inactivity. If you have a good use case for this feature, please feel free to reopen the issue.
vlsi commentedon Jul 11, 2022
I believe it is still relevant
marcphilipp commentedon Oct 23, 2026
The
gh-pagesbranch was moved to a separate repo last year https://github.com/junit-team/docs.junit.org so it no longer weighs down Git clones.