websites/Gitlab-Issue-Listing-Script#12: HTTP 500s returned

Running in a dev instance with error display turned back on, we get

<b>Fatal error</b>:  Uncaught TypeError: count(): Argument [[#1](/issue/websites/Gitlab-Issue-Listing-Script/1.html)](/issue/websites/Gitlab-Issue-Listing-Script/1.html) ($value) must be of type Countable|array, stdClass given in /var/www/html/lib/gitlab.php:226
Stack trace:
[#0](/issue/websites/Gitlab-Issue-Listing-Script/0.html) /var/www/html/lib/router.php(58): GILSGitlab-&gt;getProjectAndIssues('sysconfigs/spid...')
[[#1](/issue/websites/Gitlab-Issue-Listing-Script/1.html)](/issue/websites/Gitlab-Issue-Listing-Script/1.html) /var/www/html/index.php(12): GILSRouter-&gt;route('/project/syscon...')
[#2](/issue/websites/Gitlab-Issue-Listing-Script/2.html) {main}
  thrown in <b>/var/www/html/lib/gitlab.php</b> on line <b>226</b><br>

So, it turns out to be a weird combination of permissions.

The GILS user has permission to view the project, but not the container registry.

The call that's failing is to list containers, rather than returning an array of containers we return an object (containing the error message).

The correct way to handle this, then is to catch that error.

Actually, looking at the logs, we also get for https://gils.bentasker.co.uk/commits/_nginx_config/5f4c0a64105f7a665778793b6902dfffb6353beb.html

Updating the description

This second one is

Warning</b>:  Undefined property: stdClass::$title in <b>/var/www/html/lib/gitlab.php</b> on line <b>22</b><br />
<br />
<b>Warning</b>:  Attempt to read property "note" on string in <b>/var/www/html/lib/gitlab.php</b> on line <b>36</b><br />
<br />
<b>Fatal error</b>:  Uncaught Error: Attempt to assign property &quot;note&quot; on string in /var/www/html/lib/gitlab.php:36
Stack trace:
[#0](/issue/websites/Gitlab-Issue-Listing-Script/0.html) /var/www/html/lib/router.php(41): GILSGitlab-&gt;getCommit('_nginx_config/5...', '5f4c0a64105f7a6...')
[#1](/issue/websites/Gitlab-Issue-Listing-Script/1.html) /var/www/html/index.php(12): GILSRouter-&gt;route('/commits/_nginx...')
[#2](/issue/websites/Gitlab-Issue-Listing-Script/2.html) {main}
  thrown in <b>/var/www/html/lib/gitlab.php</b> on line <b>36</b><br />

It turns out GL will return a slightly different string if it's the project that doesn't exist.

404 Commit Not Found

vs

404 Project Not Found

That we're seeing this suggests there may be a typo somewhere - it's possible there's a bug somewhere else, or it might be that this has been incorrectly linked to from within an issue. Worth checking, but we're definitely missing group name there, and the repo name also looks fairly suspect

There's no reference in last night's backup

ben@holly:/mnt/work/gilshtml$ grep -Rl "_nginx_config/5f4c0a64105f7a665778793b6902dfffb6353beb" *
ben@holly:/mnt/work/gilshtml$ 

So it was probably introduced in the latest tag

Running a new mirror

mkdir /mnt/scratch/tmpgils
cd /mnt/scratch/tmpgils

JIRALIST="https://gils.bentasker.co.uk" # Set your JIRA url here
wget --no-check-certificate -A "$PROJECT*" -R "robots.txt" -U "Jira-Project-Archive" -r -p -k "$JIRALIST/"

Checking in that

ben@holly:/mnt/scratch/tmpgils$ grep -Rl "_nginx_config/5f4c0a64105f7a665778793b6902dfffb6353beb" *
gils.bentasker.co.uk/issue/jira-projects/LAN/5.html

ben@holly:/mnt/scratch/tmpgils$ grep -R "_nginx_config/5f4c0a64105f7a665778793b6902dfffb6353beb" *
gils.bentasker.co.uk/issue/jira-projects/LAN/5.html:                    <p>mentioned in commit sysconfigs/pihrp1<a href="https://gils.bentasker.co.uk/commits/_nginx_config/5f4c0a64105f7a665778793b6902dfffb6353beb.html">5f4c0a6</a></p>

Looks like a misfire in GILSUtils::replaceCommitRefsEtc() then

Looks like this is still an issue (from path /issue/jira-projects/LAN/5.html)

In Gitlab it looks like this

Must be something wrong with the regex, but I've got admit I don't immediately see it

It's because we don't allow numbers in project names

Adding 0-9 to the pattern has fixed that, but curiously the generated commit link 404s, so we may yet have another issue.

Trying to view any commits (/commits/sysconfigs/pihrp1_nginx_config/list.html) in that project fails, so I'm guessing this is probably permissions on Gitlab's side.

It's not permissions.

When the API call was introduced in 6c87c56e the invocation was added as

$r = $this->callAPI("GET", $url, false, false);

The result is that authentication is turned off (that final false) for the call - so we can't access the project because it's not public.

This has some overlap with #15 as that was concerned with the fact that we were only enforcing the auth toggle for the projects list.

I'll fix this under that issue - two birds, one stone etc

This is fixed.

There is, however one more thing to fix - we need to make sure that a 404 is correctly returned if a commit can't be retrieved (whether because of auth or whatever).