Add test for github format of doctest report

[user202729]

As in the title.

The feature was added in #36938 for the purpose of showing GitHub annotations for test failures, but there wasn't a doctest for it. This adds the test.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview. (no change to documentation preview because private method.)

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit 3703fb7; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[kwankyu]

I am curious why the text "Failed example" shows twice (once in red and once in black), as seen:

? Is this intended?

[user202729]

It has always been like that, but looking at what the program prints out

 ::error title=Failed example:,file=.../sage/doctest/forker.py,line=12::Failed example:
    doctest_var = 42; doctest_var^2

a reasonable guess is the part being put after title= is the red part, and the rest is the code (annotation body).
Double check.

On the other hand in the downloaded log file only

[error]Failed example:
    doctest_var = 42; doctest_var^2

would show up. This actually slightly inconvenience me in that I can't just download the log and parse it for the file and line number.

(side note: There should probably be more tests for the %0A magic and stuff.)

[kwankyu]

It has always been like that, but looking at what the program prints out

 ::error title=Failed example:,file=.../sage/doctest/forker.py,line=12::Failed example:
    doctest_var = 42; doctest_var^2

a reasonable guess is the part being put after title= is the red part, and the rest is the code (annotation body).

Yes, it seems so. Thanks.

On the other hand in the downloaded log file only

[error]Failed example:
    doctest_var = 42; doctest_var^2

would show up. This actually slightly inconvenience me in that I can't just download the log and parse it for the file and line number.

I agree. Maybe something to be improved later, if possible.

[user202729]

this tests for whole-file timeout and failed example, although using unittest instead of command-line-based test.

the long time warnings are tested in #40413, so this should be good.

[dimpase]

LGTM

[kwankyu]

Why is this PR still open?

Anyway I was waiting for an answer to the question:

Do you need the line 1261? In my experiment, you don't.

[user202729]

Ah? I can't remember what happened.

Probably because the merge accidentally remove the positive-review and I didn't notice.

Anyway, about line 1261, DTR is a global variable that might be shared between different doctests so… I figure to be safe it's best to restore the change.

After re-reading, the immediate next doctest reset DTR anyway. And it's probably cleaner to pass DD = DocTestDefaults(format='github') at constructor than to mutate it, but doesn't matter that much.

Also, this is the first time I see that comment. Maybe you didn't click "submit comments" button?

[kwankyu]

After re-reading, the immediate next doctest reset DTR anyway.

OK.

Also, this is the first time I see that comment. Maybe you didn't click "submit comments" button?

I don't know. Perhaps...since I see "Pending" tags attached to the comments.

[dimpase]

@vbraun - something fell through with the merge here?

[user202729]

more likely is I accidentally make a merge commit (93459a6) which sets the status back to need review, and I didn't notice it.

[dimpase]

then it's already merged? you can check if these changes are in the latest beta.

[user202729]

no, as in I accidentally merge latest develop into this branch, which leads to the CI being rerun and synchronize labels CI workflow set positive-review to needs-review. (well known problem with the synchronize labels CI workflow.)