visualization of new changes
Closed this issue · 6 comments
If the server is restarted or rebuilt when the latest commit is not tagged, then the url /changes returns the json
{ changes:0}
this is chached in memory and always returned afterwards, preventing the correct visualization of changes for users.
This happens because by default /changes in lib/http_version.pl obtains the log with git_shortlog, limits the results to 1 and filters the result discarding non-tagged commits. So if the last commit is not tagged, the log becomes empty and { changes:0} is returns.
Possible solutions: 1) use a larger limit for the number of commits (say 100) or 2) consider all commits and not only tagged ones. Solution 1) does not guarantee the solution if tagged commits are spaced more than 100 commits apart
There is a hook into make/0 that clears the cache. Shouldn't that be enough? I guess not if the change is not to a Prolog file but to some other file (web, examples, etc.) Still, is invalidating the cache not the way to go?
No because if after invalidating the cache the latest commit is not tagged url /changes returns the json
{ changes:0} that is stored in user localStorage and no change is anymore detected.
For example,
https://swish.swi-prolog.org/changes
returns
{ changes:0}
because the latest commit (from
https://swish.swi-prolog.org/changelog?show=all
)
is not tagged.
The way to solve it for sure would be to ask for longer and longer logs with git_shortlog until it contains a tagged commit
If you haven't updated https://swish.swi-prolog.org/ and you clear the cache, you will still get the same result
So at the moment the visualization of changes by https://swish.swi-prolog.org/ does not work
I (think I) see. I think it all works fine that if there are no tagged changes we just send the latest untagged commit ID. That should next time nicely give us the changes since that tag. Pushed a patch (59316d0) for that. Agree?
Yes, that's fine, thanks.