Worg: issue with org-tools page

Worg: issue with org-tools page

[Karl Voit]

Hi,

After fixing my WORG setup and being able to push again, I found out
that https://orgmode.org/worg/org-tools/ isn't updated by the CI
job.

https://git.sr.ht/~bzg/worg/tree/master/item/org-tools/index.org
shows the latest changes, https://orgmode.org/worg/org-tools/
doesn't.

CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of
HTML pages but for org-tools, there is no HTML output generated as
it seems. Whatever I write in org-tools/index.org doesn't get to the
HTML version of it.

Maybe somebody has an idea what's going on here?

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Karl Voit <devnull@Karl-Voit.at> writes:

> CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of
> HTML pages but for org-tools, there is no HTML output generated as
> it seems. Whatever I write in org-tools/index.org doesn't get to the
> HTML version of it.
>
> Maybe somebody has an idea what's going on here?

AFAIU, there is some problem installing "elpa-ess" Debian package. For
some reason, Emacs cannot find 'ess, which leads to export failures.

[exporting] org-contrib/babel/examples/Rpackage.org
Executing R code block at position 5615...
Cannot open load file: No such file or directory, ess

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Karl Voit]

* Ihor Radchenko <yantar92@posteo.net> wrote:
> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of
>> HTML pages but for org-tools, there is no HTML output generated as
>> it seems. Whatever I write in org-tools/index.org doesn't get to the
>> HTML version of it.
>>
>> Maybe somebody has an idea what's going on here?
>
> AFAIU, there is some problem installing "elpa-ess" Debian package. For
> some reason, Emacs cannot find 'ess, which leads to export failures.
>
> [exporting] org-contrib/babel/examples/Rpackage.org
> Executing R code block at position 5615...
> Cannot open load file: No such file or directory, ess

Okay, that was also my idea when I saw the log file. Can somebody
fix ESS here or should we convert the R blocks to a different block
type (EXAMPLE)?

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Karl Voit <devnull@Karl-Voit.at> writes:

> Okay, that was also my idea when I saw the log file. Can somebody
> fix ESS here or should we convert the R blocks to a different block
> type (EXAMPLE)?

I believe that I fixed the issue in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f

But I am not sure if I actually did. We need to trigger WORG rebuild to
see, I think.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Karl Voit]

Hi Ihor,

* Ihor Radchenko <yantar92@posteo.net> wrote:
> Karl Voit <devnull@Karl-Voit.at> writes:
>
>> Okay, that was also my idea when I saw the log file. Can somebody
>> fix ESS here or should we convert the R blocks to a different block
>> type (EXAMPLE)?
>
> I believe that I fixed the issue in
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f
>
> But I am not sure if I actually did. We need to trigger WORG rebuild to
> see, I think.

I just committed a minimal change to that file which caused the CI
to re-build the page: https://builds.sr.ht/~bzg/job/975519 which
ended successfully but still shows an error:

[...]
[exporting] org-tests/index.org
[exporting] org-tools/index.org
Executing R code block at position 5304...
Cannot open load file: No such file or directory, ess-r-mode
[exporting] org-tutorials/org-R/org-R.org
[...]

https://orgmode.org/worg/org-tools/ doesn't show the current content
from the Orgdown file.

The issue still persists.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Worg: issue with org-tools page

[Ihor Radchenko]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

Karl Voit <devnull@Karl-Voit.at> writes:

>> I believe that I fixed the issue in
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f
>>
>> But I am not sure if I actually did. We need to trigger WORG rebuild to
>> see, I think.
>
> I just committed a minimal change to that file which caused the CI
> to re-build the page: https://builds.sr.ht/~bzg/job/975519 which
> ended successfully but still shows an error:

I suspect that there is some misconfiguration of the build.
But before we go into this, let's first address the problem with
publishing being silent when some files fail to be exported.
We cannot even notice the failures now unless we check changes manually!
WORG build thinks that publishing is "success" and does not trigger
failure email.

I am attaching tentative patch that will revert demoting errors to
messages. However, I do not fully understand the purpose of the original
`condition-case' code in the publish.sh. Bastien?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-publish.sh-Trigger-error-when-any-file-fails-to-expo.patch --]
[-- Type: text/x-patch, Size: 1011 bytes --]

From 1a26aa06f1504d7c9da650c83964351f3cc61715 Mon Sep 17 00:00:00 2001
Message-ID: <1a26aa06f1504d7c9da650c83964351f3cc61715.1690632604.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sat, 29 Jul 2023 15:08:59 +0300
Subject: [PATCH] * publish.sh: Trigger error when any file fails to export

If we do not throw an error, it may go unnoticed and will not trigger
CI report.

Link: https://orgmode.org/list/2023-04-18T15-32-06@devnull.Karl-Voit.at
---
 publish.sh | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/publish.sh b/publish.sh
index fd931893..71c3a175 100755
--- a/publish.sh
+++ b/publish.sh
@@ -53,6 +53,4 @@
 	(message " [skipping] unchanged %s" org-file)
       (message "[exporting] %s" (file-relative-name org-file default-directory))
       (with-current-buffer (find-file org-file)
-	(condition-case err
-	    (org-html-export-to-html)
-          (error (message (error-message-string err))))))))
+       (org-html-export-to-html)))))
-- 
2.41.0


[-- Attachment #3: Type: text/plain, Size: 224 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Max Nikulin]

On 29/07/2023 19:14, Ihor Radchenko wrote:
> I suspect that there is some misconfiguration of the build.

Despite the .build.yml file file installs the elpa-ess package, it is 
ignored when .org files are processed due to the --quick option in 
publish.sh. Perhaps --no-init-file (-q) will help, but it may cause 
other issues. Alternatively --directory (-L) may be added to specify the 
path to the ess package explicitly. Unfortunately it will make 
publish.sh less portable.

P.S. I am in doubts if it is reasonable to execute all src blocks on 
each build since it requires enough external dependencies. Committer 
should have them installed, so their should provide proper #+results:. 
Perhaps in some cases source blocks may be re-evaluated manually, e.g. 
before releases or when babel files are changed.

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 29/07/2023 19:14, Ihor Radchenko wrote:
>> I suspect that there is some misconfiguration of the build.
>
> Despite the .build.yml file file installs the elpa-ess package, it is 
> ignored when .org files are processed due to the --quick option in 
> publish.sh. Perhaps --no-init-file (-q) will help, but it may cause 
> other issues. Alternatively --directory (-L) may be added to specify the 
> path to the ess package explicitly. Unfortunately it will make 
> publish.sh less portable.

Good catch!
I am not too concerned about portability. We already have
(load "/usr/share/emacs/site-lisp/elpa-src/htmlize-1.56/htmlize.el")
which is as bad as it can go.

> P.S. I am in doubts if it is reasonable to execute all src blocks on 
> each build since it requires enough external dependencies. Committer 
> should have them installed, so their should provide proper #+results:. 
> Perhaps in some cases source blocks may be re-evaluated manually, e.g. 
> before releases or when babel files are changed.

publish.sh already takes care about not re-exporting unchanged files.

As for re-evaluating, I see it as a minimal control for validity of WORG
examples. If necessary, we may provide an alternative publish-local.sh
to make things easier for testing locally.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Max Nikulin]

On 30/07/2023 13:40, Ihor Radchenko wrote:
> We already have
> (load "/usr/share/emacs/site-lisp/elpa-src/htmlize-1.56/htmlize.el")

--no-init-file may allow to avoid specifying versions of packages.

> publish.sh already takes care about not re-exporting unchanged files.

I do not think it has any effect. Almost certainly SourceHut workers 
start from completely clean state.

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 30/07/2023 13:40, Ihor Radchenko wrote:
>> We already have
>> (load "/usr/share/emacs/site-lisp/elpa-src/htmlize-1.56/htmlize.el")
>
> --no-init-file may allow to avoid specifying versions of packages.

Then, +1 for --no-init-file, I guess.

>> publish.sh already takes care about not re-exporting unchanged files.
>
> I do not think it has any effect. Almost certainly SourceHut workers 
> start from completely clean state.

You are right. Not that it matters too much.
The problem with dependencies is only there for local builds and that's
probably the motivation of the `condition-case' I proposed to change in
my patch. Without my patch, missing dependencies will simply fail to
export some .org sources - nothing to worry about unless the file being
edited is the one that requires missing dependency.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Max Nikulin]

On 30/07/2023 16:16, Ihor Radchenko wrote:
> The problem with dependencies is only there for local builds and that's
> probably the motivation of the `condition-case' I proposed to change in
> my patch.

Worg is a set of independent documents, so fail on first error in CI is 
reasonable mostly only if a commit may be pushed to the main branch when 
it can be built cleanly (a kind of pre-commit check). Otherwise a 
contributor may have to struggle with a problem introduced by another 
person in a completely unrelated file.

I am unsure if another workflow is suitable for Worg and SourceHut: 
changes are pushed to branches. A branch can be merged only if it can be 
built successfully. With such approach fail of first error may work.

I hope, there is a better way to address the issue with failure 
notifications.

> Without my patch, missing dependencies will simply fail to
> export some .org sources - nothing to worry about unless the file being
> edited is the one that requires missing dependency.

I would set a limit of about a dozen of failures till build process is 
not aborted.

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> On 30/07/2023 16:16, Ihor Radchenko wrote:
>> The problem with dependencies is only there for local builds and that's
>> probably the motivation of the `condition-case' I proposed to change in
>> my patch.
>
> Worg is a set of independent documents, so fail on first error in CI is 
> reasonable mostly only if a commit may be pushed to the main branch when 
> it can be built cleanly (a kind of pre-commit check). Otherwise a 
> contributor may have to struggle with a problem introduced by another 
> person in a completely unrelated file.

Fair point.

> I am unsure if another workflow is suitable for Worg and SourceHut: 
> changes are pushed to branches. A branch can be merged only if it can be 
> built successfully. With such approach fail of first error may work.
>
> I hope, there is a better way to address the issue with failure 
> notifications.

That sounds too complex.
I think we can simply add an extra "check" task to
https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
It will run after "upload", re-exporting files, but not ignoring errors
this time.
WDYT?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> I am attaching tentative patch that will revert demoting errors to
> messages. However, I do not fully understand the purpose of the original
> `condition-case' code in the publish.sh. Bastien?

Applied.  I'm aware it only fixes part of the issue at hand, but I
believe this is already better.

Thanks,

-- 
 Bastien

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> I am attaching tentative patch that will revert demoting errors to
>> messages. However, I do not fully understand the purpose of the original
>> `condition-case' code in the publish.sh. Bastien?
>
> Applied.  I'm aware it only fixes part of the issue at hand, but I
> believe this is already better.

I am not sure.
We now got exactly the concern Max raised: New commits do not update
WORG as long as even a single WORG page is broken:
https://builds.sr.ht/~bzg/job/1035051

What about the other approach I proposed?
(where we export skipping errors first, upload, and then re-export,
catching all errors this time just to trigger an email to notify about
the failure).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> I am not sure.
> We now got exactly the concern Max raised: New commits do not update
> WORG as long as even a single WORG page is broken:
> https://builds.sr.ht/~bzg/job/1035051

Mh, yes, I reverted this change.

> What about the other approach I proposed?
> (where we export skipping errors first, upload, and then re-export,
> catching all errors this time just to trigger an email to notify about
> the failure).

Yes, let's do this.

-- 
 Bastien Guerry

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> What about the other approach I proposed?
>> (where we export skipping errors first, upload, and then re-export,
>> catching all errors this time just to trigger an email to notify about
>> the failure).
>
> Yes, let's do this.

Ok. I added a new --debug command line argument to publish.sh and a new
"check" task that will generate non-zero exit code yet uploading the
successfully exported pages.

https://git.sr.ht/~bzg/worg/commit/b38a1f08
https://git.sr.ht/~bzg/worg/commit/f049752b

... And we are (hopefully) done with a side line of the original bug
report.

The original problem was
Cannot open load file: No such file or directory, ess

So, there is still a problem with ESS installation.
We may need to update the build manifest yet more.
Probably "elpa-ess" is installed into some weird place, out of
load-path.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Max Nikulin]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

On 31/07/2023 23:41, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> I hope, there is a better way to address the issue with failure
>> notifications.
> 
> That sounds too complex.
> I think we can simply add an extra "check" task to
> https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
> It will run after "upload", re-exporting files, but not ignoring errors
> this time.

I was trying to modify publish.sh to collect errors up to a reasonable 
number, a draft is attached. It can be improved further to save list of 
failures to some file, so final step of .build.yml may be to check 
whether this file is empty and to send a notification otherwise.

Currently it just prints summary of failures. When allowed failures 
count is exceeded, it fails immediately.

./publish.sh --maxfail 32
...
org-release-notes.org: Could not find plantuml.jar at 
/usr/share/plantuml/plantuml.jar
org-faq.org: Could not find ditaa.jar at /usr/bin/ditaa
org-blog-wiki.org: Unable to resolve link: 
"[https://github.com/kaushalmodi/ox-hugo/tree/master/test/site/content-org"
library-of-babel.org: Symbol’s function definition is void: fib
org-tutorials/images-and-xhtml-export.org: Unable to resolve link: 
"worg/images/orgmode/org-mode-unicorn.png"
org-tools/index.org: Cannot open load file: No such file or directory, ess
org-contrib/babel/intro.org: Could not find ditaa.jar at /usr/bin/ditaa
org-contrib/babel/languages/ob-doc-scheme.org: Symbol’s value as 
variable is void: geiser-default-implementation
org-contrib/babel/languages/ob-doc-ditaa.org: Could not find ditaa.jar 
at /usr/bin/ditaa
org-contrib/babel/languages/ob-doc-LaTeX.org: Cannot open load file: No 
such file or directory, ess
org-contrib/babel/examples/org-check.org: Symbol’s value as variable is 
void: org-latex-to-pdf-process
org-contrib/babel/examples/lob-table-operations.org: Symbol’s function 
definition is void: flet
org-contrib/babel/examples/foo.org: Inline error: list result cannot be used
org-contrib/babel/examples/drift.org: Could not find ditaa.jar at 
/usr/bin/ditaa
org-contrib/babel/examples/data-collection-analysis.org: Cannot open 
load file: No such file or directory, ess
org-contrib/babel/examples/ascii.org: Cannot open load file: No such 
file or directory, ess
org-contrib/babel/examples/Rpackage.org: Cannot open load file: No such 
file or directory, ess


[-- Attachment #2: publish.sh --]
[-- Type: application/x-shellscript, Size: 5204 bytes --]

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> I was trying to modify publish.sh to collect errors up to a reasonable 
> number, a draft is attached. It can be improved further to save list of 
> failures to some file, so final step of .build.yml may be to check 
> whether this file is empty and to send a notification otherwise.
>
> Currently it just prints summary of failures. When allowed failures 
> count is exceeded, it fails immediately.
>
> ./publish.sh --maxfail 32

I am not sure why it would be useful to limit the number of errors to
anything other than 0/infinity.

Note that I just pushed an alternative (but very similar) change in
https://git.sr.ht/~bzg/worg/commit/b38a1f08

If you think that my commit can be improved, feel free to do it.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> So, there is still a problem with ESS installation.
> We may need to update the build manifest yet more.
> Probably "elpa-ess" is installed into some weird place, out of
> load-path.

I added the load-path for ess, this seems to work.

I also added the gnuplot dependency in the build manifest, hopefully
this fixes the last error I've seen.

-- 
 Bastien Guerry

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> So, there is still a problem with ESS installation.
>> We may need to update the build manifest yet more.
>> Probably "elpa-ess" is installed into some weird place, out of
>> load-path.
>
> I added the load-path for ess, this seems to work.

May it be enough to drop --quick in Emacs call from publish.sh instead
of manually adding system-installed Emacs packages?

--quick implies -q --no-site-file --no-splash and --no-site-file
prevents loading Emacs packages installed by apt, AFAIU.

So, we might simply use --no-init-file --no-splash.

Also, re: f32704bbbd97 publish.sh: Set ess vars to nil

We probably need to deal with it on Org side.
See https://list.orgmode.org/orgmode/alpine.DEB.2.22.394.2211132209230.150678@shell3.miskatonic.org/

> I also added the gnuplot dependency in the build manifest, hopefully
> this fixes the last error I've seen.

There seems to be a general problem with some blocks being executed when
they are not supposed to.

In 515c8b75 org-contrib/babel/examples/Rpackage.org, the problematic
block is not supposed to be evaluated during export!
Similar situation with the latest failure
https://builds.sr.ht/~bzg/job/1035804 where blocks in
data-collection-analysis.org are clearly not intended for evaluation.

May we just set #+PROPERTY: header-args :eval no-export across examples?
Or, more generally, avoid evaluating blocks unless explicitly enabled
across all Org files (to be future-proof).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Max Nikulin]

On 05/08/2023 19:23, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> I was trying to modify publish.sh to collect errors up to a reasonable
>> number, a draft is attached.
...
>> Currently it just prints summary of failures. When allowed failures
>> count is exceeded, it fails immediately.
>>
>> ./publish.sh --maxfail 32
> 
> I am not sure why it would be useful to limit the number of errors to
> anything other than 0/infinity.

You have agreed that aborting of upload on any error may be 
disappointing when the error was introduced by another person.

If there are dozens of failures then something serious has happened 
either with Org or with Worg and it is a reason to not upload partial 
results.

I believe that list of 5-10 failed files is suitable for notification 
failure (e-mail, instant messaging, etc.).

> Note that I just pushed an alternative (but very similar) change in
> https://git.sr.ht/~bzg/worg/commit/b38a1f08

It fails on first error. I find a report containing several errors much 
more helpful for figuring out what has actually happened. On the other 
hand there should be a strong reason to read all errors when there are 
hundreds one.

P.S. You have not documented that your approach abuses --debug-init 
standard Emacs option.

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> I am not sure why it would be useful to limit the number of errors to
>> anything other than 0/infinity.
>
> You have agreed that aborting of upload on any error may be 
> disappointing when the error was introduced by another person.

This will not happen now.
See https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
The error is only reported after "upload" via "check" task.

> If there are dozens of failures then something serious has happened 
> either with Org or with Worg and it is a reason to not upload partial 
> results.
>
> I believe that list of 5-10 failed files is suitable for notification 
> failure (e-mail, instant messaging, etc.).

Even a single failed file should trigger e-mail notification.

As for dozens of failures caused by something serious, I do hope that
Org commiters are careful enough. WORG uses bugfix version of Org where
we already push with care, when we are confident that things should not
break even theoretically. And if the large failures are caused by WORG
commit, it should be a commit either touching the build system or basic
WORG includes - such commits should be taken with care anyway.

In summary, I do not think that we should be concerned about downtime
caused by accidental and _also very serious_ issue caused by careless
commit. If we do encounter such scenarios, it will be a sign that we
should switch to a proper testing/production website builds; not trying
to re-invent the wheel with ad-hoc build script solutions.

>> Note that I just pushed an alternative (but very similar) change in
>> https://git.sr.ht/~bzg/worg/commit/b38a1f08
>
> It fails on first error. I find a report containing several errors much 
> more helpful for figuring out what has actually happened. On the other 
> hand there should be a strong reason to read all errors when there are 
> hundreds one.

You are right. I will see what I can do to throw exit only at the end,
showing all the errors.

> P.S. You have not documented that your approach abuses --debug-init 
> standard Emacs option.

My approach does not abuse --debug-init. The new cmd line argument is --debug.
I have no opinion about which header argument should be used. You can
propose an alternative, if you find something more self-explanatory and
not clashing with the existing Emacs command line args.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Bastien Guerry]

Ihor Radchenko <yantar92@posteo.net> writes:

> May it be enough to drop --quick in Emacs call from publish.sh instead
> of manually adding system-installed Emacs packages?

Indeed.  Please go ahead: experimental commits won't hurt much.

> May we just set #+PROPERTY: header-args :eval no-export across
> examples?

Sure, please go ahead as you see fit!

-- 
 Bastien Guerry

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> May it be enough to drop --quick in Emacs call from publish.sh instead
>> of manually adding system-installed Emacs packages?
>
> Indeed.  Please go ahead: experimental commits won't hurt much.

Done.
https://git.sr.ht/~bzg/worg/commit/01f6d31a

>> May we just set #+PROPERTY: header-args :eval no-export across
>> examples?
>
> Sure, please go ahead as you see fit!

Done.
https://git.sr.ht/~bzg/worg/commit/8370cbd7

A number of code blocks never evaluated even in the past. In particular,
for org-contrib/babel/foo-doc.org files. I have enabled evaluation for
the files where we already load ob-foo, but not for others. To keep
status quo. But we may consider not evaluating anything in there and
instead relying upon the original results present in the .org sources.
At the end, WORG publishing is not our CI test pipeline.

I already had to work around some ESS bug to make things publish with
Emacs 29:
https://git.sr.ht/~bzg/worg/commit/4976d418

And I can see that it is not all yet. There is some major change in the
latest ESS that is causing ob-R to fail (see our latest R session test
failures in sr.ht CI). It is also preventing publishing because Org
attempts to evaluate some R code blocks, fails, and gives up.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Bastien Guerry]

Thanks for the fixes!

Ihor Radchenko <yantar92@posteo.net> writes:

> And I can see that it is not all yet. There is some major change in the
> latest ESS that is causing ob-R to fail (see our latest R session test
> failures in sr.ht CI). It is also preventing publishing because Org
> attempts to evaluate some R code blocks, fails, and gives up.

Yes.  I hope other Org/ESS/R users on this list will help fixing these
documentation issues on WORG.

-- 
 Bastien Guerry

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Ihor Radchenko <yantar92@posteo.net> writes:

>>> Note that I just pushed an alternative (but very similar) change in
>>> https://git.sr.ht/~bzg/worg/commit/b38a1f08
>>
>> It fails on first error. I find a report containing several errors much 
>> more helpful for figuring out what has actually happened. On the other 
>> hand there should be a strong reason to read all errors when there are 
>> hundreds one.
>
> You are right. I will see what I can do to throw exit only at the end,
> showing all the errors.

Unfortunately, I was not able to find a way to do it and yet display the
error backtraces.

The best we can do is using  `backtrace-get-frames' in the error
handler:

(backtrace-to-string (backtrace-get-frames 'backtrace))

But it will only display backtrace down to `condition-case' entry - not
very useful in practice.

So, I think that the best option we have is stopping on the first error
and displaying backtrace - it will provide as much information as
possible to diagnose the cause.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Worg: issue with org-tools page

[Max Nikulin]

On 09/08/2023 14:44, Ihor Radchenko wrote:
> 
> Unfortunately, I was not able to find a way to do it and yet display the
> error backtraces.
> 
> The best we can do is using  `backtrace-get-frames' in the error
> handler:

My version of the script prints allowed number of error messages and 
stack of the error that exceeds the count. I decided that it provides 
better balance of details. However printing at least one error stack may 
be better.

Re: Worg: issue with org-tools page

[Ihor Radchenko]

Karl Voit <devnull@Karl-Voit.at> writes:

> I just committed a minimal change to that file which caused the CI
> to re-build the page: https://builds.sr.ht/~bzg/job/975519 which
> ended successfully but still shows an error:
> from the Orgdown file.
> ...
> The issue still persists.

I can finally see this update being published.
There are still some failures to be fixed, but they will now be reported
at https://lists.sr.ht/~bzg/org-build-failures and we should not miss
them.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>