mainSavannah Administration - Support: sr #110871, cgit sometimes renders commits as...

 
 

sr #110871: cgit sometimes renders commits as "no repositories found"

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Fri 21 Apr 2023 09:21:34 AM UTC
   
 
Category:  Source code repositories - web browsing Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  ineiev
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 22 Apr 2023 07:35:33 AM UTC, comment #7: 

Hi Iniev,

I clicked through "parent" links through 106 commits from about 2:31:00 to 2:33:00 my local time without ever hitting this problem.  At that pace I should very likely have hit the 5-second bug window.

So as far as I'm concerned, you're resolved the issue.

Thanks!

G. Branden Robinson <gbranden>
Sat 22 Apr 2023 07:20:42 AM UTC, comment #6: 


comment #5:

> > I'll try to use a temporary file.
>
> Done; please test, the cron job still runs at minutes 2 and 32 every hour, it typically ends within 5 seconds.


Cool, thank you!  It's hard to prove a negative but I'll take another crack it here in about 10 minutes.  The times I've seen it before, the "persistence" of the error page must have been simply due to client-side caching.

G. Branden Robinson <gbranden>
Sat 22 Apr 2023 07:08:29 AM UTC, comment #5: 


> I'll try to use a temporary file.


Done; please test, the cron job still runs at minutes 2 and 32 every hour, it typically ends within 5 seconds.

Ineiev <ineiev>
Site Administrator
Fri 21 Apr 2023 10:03:23 AM UTC, comment #4: 

The list of repos for cgit is updated on 2,32 on vcs2, and it does look like that the updating isn't practically atomic:


open(OUT, ">/srv/git/cgitrepos") or die $!;
foreach my $line (@db) {
    my ($unix_group_name, $group_name, $dir_git) = @{$line};
    my $path = $dir_git;
    $path =~ s/%PROJECT/$unix_group_name/;

    next if (! -e $path); # not replicated yet

    my $desc = '';
    open(DESC, "<$path/description") or warn $!;
    $desc = <DESC>;
    close(DESC);
    chomp($desc);
    $desc = '' if $desc =~ /Unnamed repository/;
...
            print OUT <<EOF;
repo.url=$unix_group_name/$subrepo
repo.path=$subrepos_dir/$subrepo
repo.desc=$desc
repo.readme=README.html
repo.owner=$gitweb_owner
EOF
        }
    }
}
close(OUT);


I'll try to use a temporary file.

Ineiev <ineiev>
Site Administrator
Fri 21 Apr 2023 09:36:47 AM UTC, comment #3: 

I can't reproduce this.  git-gc runs on 5 1 4,11,18,25 and definitely doesn't overlap to the next day, so it looks like a cgit issue.

Ineiev <ineiev>
Site Administrator
Fri 21 Apr 2023 09:21:34 AM UTC, comment #2: 

This item has been reassigned from the project Savannah Administration task tracker to your tracker.

The original report is still available at task #16361

Following are the information included in the original report:

[field #0]                  Item ID: 16361

[field #1]                 Group ID: 5802

[field #2]              Open/Closed: Open

[field #3]                 Severity: 3 - Normal

[field #4]                  Privacy: Public

[field #8]                         : Unknown task Field Display Type

[field #9]                 Category: Misdirected Items

[field #10]                Submitter: gbranden

[field #11]              Assigned to: None

[field #12]                Submitted: Fri 21 Apr 2023 09:06:55 AM UTC

[field #13]                  Summary: cgit sometimes renders commits as "no repositories found"

[field #14]      Original Submission: This seems to go away after one pushes another commit to the repository, changing its state, but it recurs, with different commits, over time.

Here's an example.  Because of the above factor I don't know how long it will remain in place, but I'm the most frequent committer to the repo, so I will try to hold off until you can reproduce it.  I'll send an announcement to the groff list asking others to hold off as well.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=312857800eceb5a49f3f3f4aed990dc3b63ea4f0

Nothing seems to be wrong with that commit ID in my local, up-to-date working of the master branch with no subsequent changes.

Please let me know when you've gathered the artifacts you need so we can resume activity; we're trying to prepare groff of release (we tagged a fourth release candidate last weekend).




[field #16]               Item Group: None

[field #17]                   Status: None

[field #18]        Component Version: None

[field #19]         Operating System: None

[field #20]          Reproducibility: None

[field #21]               Size (loc): None

[field #22]            Fixed Release: None

[field #23]          Planned Release: None

[field #24]                   Effort: 0.00

[field #28]                 Priority: 5 - Normal

[field #29]          Should Start On: Fri 21 Apr 2023 12:00:00 AM UTC

[field #30]    Should be Finished on: Sun 21 May 2023 12:00:00 AM UTC

[field #31]         Percent Complete: 0%

[field #33]                  Release: None

[field #58]     Custom Select Box #1: None

[field #59]     Custom Select Box #2: None

[field #60]     Custom Select Box #3: None

[field #61]     Custom Select Box #4: None

[field #62]     Custom Select Box #5: None

[field #63]     Custom Select Box #6: None

[field #64]     Custom Select Box #7: None

[field #65]     Custom Select Box #8: None

[field #66]     Custom Select Box #9: None

[field #67]    Custom Select Box #10: None


Ineiev <ineiev>
Site Administrator
Fri 21 Apr 2023 09:13:23 AM UTC, comment #1: 

Nope, it's gone again.

But this keeps happening.  Any ideas?  Does some robot periodically repack each Git repository's internal data but the operation is not atomic/invisible to the web interface, so it occasionally catches items mid-cleanup?

G. Branden Robinson <gbranden>
Fri 21 Apr 2023 09:21:34 AM UTC, original submission:  

This seems to go away after one pushes another commit to the repository, changing its state, but it recurs, with different commits, over time.

Here's an example.  Because of the above factor I don't know how long it will remain in place, but I'm the most frequent committer to the repo, so I will try to hold off until you can reproduce it.  I'll send an announcement to the groff list asking others to hold off as well.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=312857800eceb5a49f3f3f4aed990dc3b63ea4f0

Nothing seems to be wrong with that commit ID in my local, up-to-date working of the master branch with no subsequent changes.

Please let me know when you've gathered the artifacts you need so we can resume activity; we're trying to prepare groff of release (we tagged a fourth release candidate last weekend).


G. Branden Robinson <gbranden>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Updated the item)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-04-24 ineiev StatusReady For Test Done
        Open/ClosedOpen Closed
    2023-04-22 ineiev StatusIn Progress Ready For Test
    2023-04-21 ineiev StatusNeed Info In Progress
        Assigned toNone ineiev
    2023-04-21 ineiev CategoryNone Source code repositories - web browsing
        StatusNone Need Info
    2023-04-21 ineiev Reassign itemSavannah Administration, task #16361 Savannah Administration, sr #110871

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code