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.