Please consider moving gh-pages to another repository and/or reduce the size of the branch

[vlsi]

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.

1. Are PDFs required? Could they be pushed somewhere else? Do all the snapshots need to be stored in the main repository?

2. Could you please consider the use of noTimestamp for the javadoc? 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

[vlsi]

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]

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_pages branch to a new junit5 subdir in https://github.com/junit-team/junit-team.github.io?

[vlsi]

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]

I think that would be ok. Or we could keep the manual commits and squash all others?

[marcphilipp]

FWIW we already set noTimestamp:

junit5/documentation/documentation.gradle.kts

Line 234 in 6f979d6

noTimestamp(true)

[vlsi]

Or we could keep the manual commits and squash all others?

It could make sense. For instance, if the latest commit is automatic, then amend it + force-push-with-lease.

[marcphilipp]

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-pages branch 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]

👍

Pruning old or even all versions of committed PDF files would shrink the repository size even further.

[marcphilipp]

New plan: Move to https://github.com/junit-team/junit-team.github.io

[vlsi]

Are you going to shrink pdfs there as well?

[marcphilipp]

@vlsi How would you shrink them?

[vlsi]

I assume nobody really needs historical snapshot PDFs.
So you could keep just the latest version of the file.
Or you could refrain from constantly pushing PDFs as they are not diffed well (== Git can't compress PDF files via delta-encoding).

[marcphilipp]

I guess we could build them (in order to be sure they actually build) but not publish them for snapshots.

[vlsi]

That would work.
GitHub is infinite, and it would be great to use the resources in a fair manner.

[marcphilipp]

I did that as a first step in order to stop its growth: cf19ffd

[stale]

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]

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.

[marcphilipp]

I think we should still do this.

[vlsi]

Just in case, actions/checkout no longer fetches all branches and tags, so it is fast.

[stale]

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]

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]

I believe it is still relevant