Add a Circle CI job to show a preview of the docs on PRs

[asmeurer]

Fixes #23460.

References to other Issues or PRs

Brief description of what is fixed or changed

Other comments

Release Notes

NO ENTRY

[sympy-bot]

✅

Hi, I am the SymPy bot (v167). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

• No release notes entry will be added for this pull request.

Click here to see the pull request description that was parsed.

Fixes #23460.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed


#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
NO ENTRY
<!-- END RELEASE NOTES -->

[sympy-bot]

🟠

Hi, I am the SymPy bot (v167). I've noticed that some of your commits add or delete files. Since this is sometimes done unintentionally, I wanted to alert you about it.

This is an experimental feature of SymPy Bot. If you have any feedback on it, please comment at sympy/sympy-bot#75.

The following commits add new files:

• df241d6:
  • .circleci/config.yml
  • .github/workflows/docs-preview.yml

If these files were added/deleted on purpose, you can ignore this message.

[asmeurer]

I pushed this branch to the main repo so I can test it before merging.

[asmeurer]

Circle worked but I can't get the GitHub Actions build to appear (maybe I just need to wait?).

Also the authors build is failing with some bug. Is it because it's on a "push" build instead of a PR build?

[github-actions]

Benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1
means a speed up and greater than 1 means a slowdown. Green lines
beginning with + are slowdowns (the PR is slower then master or
master is slower than the previous release). Red lines beginning
with - are speedups.

Significantly changed benchmark results (PR vs master)

Significantly changed benchmark results (master vs previous release)

       before           after         ratio
     [77f1d79c]       [107a6793]
     <sympy-1.10.1^0>                 
+      99.7±0.9ms        180±0.8ms     1.81  sum.TimeSum.time_doit

Full benchmark results can be found as artifacts in GitHub Actions
(click on checks at the top of the PR).

[asmeurer]

The page for the GitHub Actions says this might not work for PRs from forks. But it seems to work on every NumPy PR I checked, so I'm not sure if that's still true. If it doesn't work we can switch to Jason's idea.

[oscarbenjamin]

The page for the GitHub Actions says this might not work for PRs from forks.

This is the reason that the benchmarks comment-on-pr workflow is separate from the main runtests workflow. Basically the runtests workflow doesn't have permissions to do things like comment on a PR. A separate workflow that runs with the master branch version of the workflow files can have these permissions.

[oscarbenjamin]

I see that the authors test is failing:

Run bin/mailmap_check.py --skip-last-commit
fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Traceback (most recent call last):
  File "/home/runner/work/sympy/sympy/bin/mailmap_check.py", line 327, in <module>
    sys.exit(main(*sys.argv[[1](https://github.com/sympy/sympy/runs/6298124542?check_suite_focus=true#step:6:1):]))
  File "/home/runner/work/sympy/sympy/bin/mailmap_check.py", line 56, in main
    git_people = get_authors_from_git(skip_last=args.skip_last_commit)
  File "/home/runner/work/sympy/sympy/bin/mailmap_check.py", line 252, in get_authors_from_git
    move(git_people, 2, 0, 'Ondřej Čertík')
  File "/home/runner/work/sympy/sympy/bin/mailmap_check.py", line 246, in move
    x = l.pop(i1)
IndexError: pop index out of range
Error: Process completed with exit code 1.

That ("unknown revision") suggests that the commit use in CI (in the runtests workflow) doesn't have two ancestors for the merge commit. Not sure why that might be...

[asmeurer]

That ("unknown revision") suggests that the commit use in CI (in the runtests workflow) doesn't have two ancestors for the merge commit. Not sure why that might be...

Because it's a "push" build. I pushed the branch directly up to the repo in addition to my fork so that I could test Circle without merging. You'll probably get the same error whenever you make a release branch.

[asmeurer]

A separate workflow that runs with the master branch version of the workflow files can have these permissions.

I wonder if that's why the GitHub Actions preview "build" isn't showing up. Where are those permissions set?

[asmeurer]

I removed the merge logic from the authors script, and it seems to be passing. Was it adding some special GitHub user for the merge commit before? It doesn't seem to be doing that https://github.com/sympy/sympy/runs/6314266852?check_suite_focus=true#step:6:12

[asmeurer]

I can't figure out how to make the actual GitHub Actions step of this work. It isn't reporting the status with the link to the built page. Maybe it would only work once it is in master itself, although it seems to me it ought to at least work on the push build.

[oscarbenjamin]

I removed the merge logic from the authors script, and it seems to be passing.

The merge logic is needed for someone who has correctly set up their metadata in their commits (with git config) but whose github settings mean that github uses different metadata in any commits that it creates for them: #23265 (comment).

[oscarbenjamin]

A separate workflow that runs with the master branch version of the workflow files can have these permissions.

I wonder if that's why the GitHub Actions preview "build" isn't showing up. Where are those permissions set?

You can't control the permissions that I am referring to. Anyone can create a fork and open a PR which modifies the workflow files. GA will then perform the actions described in the modified workflow files. Hence the workflows triggered by the PR need to have limited permissions. If you want a job to run with more permissions then you need to ensure that it runs with the unmodified workflow files.

[asmeurer]

OK, I can't figure out how to get the GitHub Actions link to actually show up. I even tried making a PR within the same repo so there are no forks, and it didn't work there either #23469. @larsoner do you have any suggestions? I've more or less directly copied this from another repo where I know it works.

The only thing I can think of is that it has to be merged into master first before it will work. I do already have this as a branch pushed to the main repo, so it seems to me that ought to be enough, but maybe it isn't. So we can try merging this. @oscarbenjamin are you OK with the mailmap_update change?

If we can't get this working, I guess we can try using @moorepants's approach instead.

[asmeurer]

Oh I didn't see your comments. I'll just revert the mailmap script change. You might need to do something about it for the release branch later. I'm also surprised it doesn't cause the master builds to fail.

It sounds pretty likely that this just isn't working because it isn't in master. Since I can't think of anything else, I'm just going to merge this (after reverting the mailmap script change). If it doesn't work then, I'll keep hammering on it, or try Jason's approach if I can't figure it out.

[larsoner]

The only thing I can think of is that it has to be merged into master first before it will work.

Yes because it operates on the [status] event that only gets processed on main AFAIK, you'll probably have to merge it and then see if it works