Closed yarikoptic closed 1 year ago
@yarikoptic So you want a gh-pages site for datalad/git-annex-ci-client-jobs (Setting this up for this repo wouldn't be simple) that displays — what, exactly? The same contents as the daily e-mail? And then this repo's README links to that site?
just what we have in daily email. It seems it is not per job, but per client, e.g.
ndoli #737 [download logs] 2022-06-23 04:34:03+00:00
smaug #737 [download logs] 2022-06-23 04:08:42+00:00
so the idea then would be to add a hyperlink at the level of a client ... I do not think we can also get URL per each client workflow since we do not want to update README.md all the time, so we would need to point to filter of actions results, e.g. https://github.com/datalad/git-annex-ci-client-jobs/actions?query=result-ndoli for ndoli and https://github.com/datalad/git-annex-ci-client-jobs/actions?query=result-smaug for smaug -- but that thing also includes results for ndoli. Do you see how to limit more 'specifically'?
@yarikoptic I'm still not clear on what exactly you want this GH Pages site to show. Do you only want links for the ndoli & smaug tests, or also for the datalad/git-annex tests? And what should be shown for each test/client?
It seems it is not per job, but per client
Technically, the daily e-mail shows every client run for the past 24 hours, but the clients only run in response to scheduled datalad/git-annex builds, so there's only one per client per day.
but that thing also includes results for ndoli. Do you see how to limit more 'specifically'?
No. I tried filtering the branch by both result-smaug-
and result-smaug-*
, but that didn't work.
@yarikoptic I'm still not clear on what exactly you want this GH Pages site to show. Do you only want links for the ndoli & smaug tests, or also for the datalad/git-annex tests?
Pretty much I think we need the same content as in the daily email -- can simply reuse that code and keep dumping those reports in e.g. YEAR/MONTH/DATE or alike hierarchy with some latest
symlink pointing to the most recent one.
And what should be shown for each test/client?
should be sufficient as in the email, so per client run I think.
@yarikoptic To summarize, you want:
{year}/{month}/{date}
hierarchy with a latest
symlink (where?) pointing to the most recent oneAm I missing anything?
@yarikoptic To summarize, you want:
- a gh-pages site for this repository that displays the same HTML as the most recent daily status e-mail and is updated at the same time that the e-mail is sent
yes
- The gh-pages branch should be updated by amending the history so as not to bloat the repository more.
I take this back -- let's not bother updating the history (see below)
- the daily status reports' HTML to be archived (where?) in a
{year}/{month}/{date}
hierarchy with alatest
symlink (where?) pointing to the most recent one
What about, to not interfere with other clones etc, place all those into a new dedicated repo https://github.com/datalad/git-annex-ci-reports? No need really for having it as a gh-pages I guess as long as we have all needed files conveniently available. I have made it to publish from master. Can be seen at https://datalad.github.io/git-annex-ci-reports/
Note that I had to add <html><body>
tags into report.html .
At top level we would have index.html
symlink to point to the most latest report. In the report .html, I added added HTML id
s so we could direct to the corresponding paragraph at least.
I made them into a folder thinking may be per each client we also better produce a little redirector page which would jump to corresponding log link, so we would have a file per client in that folder (I didn't do it in the demo). But I think we are just as fine with those HTML id and #id
URLs, so feel welcome to redo so it is {Y}/{M}/{D}-{HHMM}.html
.
a link to the root(?) of the gh-pages site to be added to the README
- Or do you want each client name in the "Client Tests" table in the README (and/or something for the platform status badges in the preceding section? something else?) to link to the corresponding client sections of the root page of the gh-pages site?
for each client - for its name, make hyperlink to https://datalad.github.io/git-annex-ci-reports/#{client-id}
.
Also may be for the email body -- please add on top the permalink to {Y}/{M}/{D}-{HHMM}.html
place so we
* As the daily status report is organized by job rather than by platform/client, what should the link target be when there are multiple jobs for a platform/client?
I would not do anything special. I guess if multiple <p id="ID">
would be there -- browser would go to the first
Am I missing anything?
I think we have it all above ;)
@yarikoptic
{HHMM}
is meant to be.) The daily statuses are only supposed to be generated once a day.
- What's the pont of including the time in the HTML filename? (I assume that's what the
{HHMM}
is meant to be.) The daily statuses are only supposed to be generated once a day.
Just so that we disambiguate in case we for some reason run may be twice (unlikely to collide in {HHMM}
). But I do not feel strongly about it -- feel free to just use date
- Technically, I believe an HTML page with multiple occurrences of the same ID is invalid, so a browser is allowed to do anything.
you are welcome to insert id
only into the first one.
@yarikoptic
Note that I had to add
<html><body>
tags into report.html .
Why exactly did you have to do this? Was the lack of these tags causing a problem somehow? I would expect any browser to render the page just fine without them.
@yarikoptic
Note that I had to add
<html><body>
tags into report.html .Why exactly did you have to do this? Was the lack of these tags causing a problem somehow? I would expect any browser to render the page just fine without them.
I thought that having those is a part of the HTML standard... and indeed https://validator.w3.org/nu/?doc=https%3A%2F%2Fraw.githubusercontent.com%2Fdatalad%2Fgit-annex-ci-reports%2Feebc4868b4903369d756fcf90dd2bbe237548367%2F2023%2F05%2F18%2Freport.html even refuses to validate it.
@yarikoptic I believe the problem there is that GitHub (for whatever reason) reports the file's Content-Type as text/plain, so the validator isn't even going to bother with the contents. If you download the file and open it locally in a browser, are there problems?
browsers are indeed resilient, but that is not a reason why not to satisfy the standard I think.
<body>
) fixed up (note that needed closing an </li>
and </ul>
, added a title) http://www.oneukrainian.com/tmp/report_fixed.html .--- report.html 2023-05-19 09:32:32.000000000 -0400
+++ report_fixed.html 2023-05-19 09:42:09.000000000 -0400
@@ -1,3 +1,10 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta http-equiv="Content-Type"
+ content="text/html; charset=utf-8">
+<title>git-annex testing status report from 2023-05-18 05:00</title>
+</head>
<ul>
<li><p>GitHub:</p>
<ul>
@@ -54,4 +61,5 @@
<li><span style="color: green">PASS</span> git-annex</li>
</ul></li>
</ul>
-
+</li></ul>
+</html>
ATM they just point to images and it is not "easy" to get to get to the logs. The daily mail, which I love, has all those references which should also be in the README.md . But we would not want to commit changes to README.md so we would need to establish some redirection which would be updated daily (e.g along with sending that status email). I guess it could be some gh-pages page(s) purely with redirects, and that gh-pages branch to contain rewritable commit so we do not grow history.