CI: Merge open blocker PRs in all CI workflows + other improvements #36338

mkoeppe · 2023-09-25T23:34:31Z

The new script .ci/merge-fixes.sh uses the GitHub CLI to retrieve open PRs with the "blocker" label from sagemath/sage and tries to merge them into the tested branch, ignoring any PRs that give merge failures.

We call this script in all CI workflows. Thus,

hotfixes for the linter (such as fix the linter once more #36327) or
fixes for build problems (such as Yet more spkg_configure for standard python packages #36276)

will take effect in the CI workflows of all PRs.

This can be seen in the runs of the workflows of the present PR (section "Merge CI fixes from sagemath/sage").

Additionally,

we fix debian-trixie, which failed because a system package is no longer available
we fix macos-conda-maximal by removing some fictitious distros/conda.txt files
we refactor ci-macos using a new reusable workflow; example runs:
- https://github.com/mkoeppe/sage/actions/runs/6308124398
- https://github.com/sagemath/cysignals/actions/runs/6316714387?pr=185
we update the ci-macos platforms, including a configuration for the new and problematic Xcode 15.0

📝 Checklist

The title is concise, informative, and self-explanatory.
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 accordingly.

⌛ Dependencies

…w macos.yml, update macOS, Xcode versions

… is not needed in the container

kliem · 2023-09-26T06:40:57Z

.ci/merge-fixes.sh

+# Merge open PRs from sagemath/sage labeled "blocker".
+REPO="sagemath/sage"
+GH="gh -R $REPO"
+PRs="$($GH pr list --label "p: blocker / 1" --json number --jq '.[].number')"


Interesting approach. There is a couple of thoughts I have about this:

We would merge any blocker PR. Is there any quality control, e.g. pipeline passed etc. or positively reviewed.

This would self-reference blockers.

Unless we merge in all blockers first, we might merge in PRs that depend on blockers, but do not declare that dependency correctly.

Would there still be a sanity check that just tests this PR without merging in other things?

We would merge any blocker PR. Is there any quality control, e.g. pipeline passed etc. or positively reviewed.

There isn't, and I don't think it's needed. Since the transition to GitHub, using priority labels has become pretty rare, and no one has used the blocker tag without a good reason.

This would self-reference blockers.

Yes, but for these the merge would be a no-op, and I think I'm handling this correctly in the scripts.

EDIT: See the run for the current workflow.

Unless we merge in all blockers first, we might merge in PRs that depend on blockers, but do not declare that dependency correctly.

Currently, the release manager scripts ignore all dependencies and all priorities anyway...

Sounds plausible.

tobiasdiez · 2023-09-26T17:01:59Z

I am not the biggest fan of this auto-apply of blocker PRs in all work flows. I think it would be better to attack the issue at the root and make it impossible to merge PRs with failing workflows. Everything else feels like a weird hack, especially since one still has to create these hotfix PRs in the first place.

mkoeppe · 2023-09-26T18:02:15Z

Yes, this PR is a practical solution. It is designed to avoid two approaches, each of which would be more elegant:

It does not create hotfix branches explicitly. Hence, there is no hotfix branch to maintain; hence there is not need for a maintainer of the hotfix branch.
It does not require communication with the release manager.

This careful design makes this PR an effective solution.

… handling

kliem · 2023-09-26T19:01:24Z

The CI is rather fragile depending on a bunch of system packages (and so is the entire installation process). Package updates will break building on certain environments. So I think this is a reasonable solution. Hotfixes are applied on the CI immediately and eliminate noise for which those authors are not responsible.

One should agree thought that the blocker label is only applied once the author confident that this is a solution.

mkoeppe · 2023-09-26T19:07:09Z

Thanks @kliem

One should agree though that the blocker label is only applied once the author confident that this is a solution.

Setting the priority label is limited to the Triage role; I think we can trust that developers who have been elevated to this role will not abuse it.

kliem · 2023-09-26T19:17:10Z

Thanks @kliem

One should agree though that the blocker label is only applied once the author confident that this is a solution.

Setting the priority label is limited to the Triage role; I think we can trust that developers who have been elevated to this role will not abuse it.

Cool. As you noticed, I'm not very involved at the moment and I wasn't aware that the move to github enabled more granular control of such things.

tobiasdiez · 2023-09-26T22:32:51Z

The CI is rather fragile depending on a bunch of system packages (and so is the entire installation process). Package updates will break building on certain environments. So I think this is a reasonable solution.

Thats not the problem. The CI doesn't randomly fails. It fails because PRs with broken CI are merged since the release manager takes only a different set of CI checks into account.

A more elegant and effective solution would be to enable and enforce branch protection rules. But yes, that would require input from @vbraun.

dimpase

lgtm. At worst, we break CI if it doesn't quite work.

github-actions · 2023-09-27T00:26:39Z

Documentation preview for this PR (built with commit b14ef26; changes) is ready! 🎉

kwankyu · 2023-09-27T02:20:52Z

All checks passed! 🎉

Merging CI-fixes immediately to CI-workflows is a great idea. Thanks!

tobiasdiez · 2023-09-27T02:28:31Z

.ci/merge-fixes.sh

+# Merge open PRs from sagemath/sage labeled "blocker".
+REPO="sagemath/sage"
+GH="gh -R $REPO"
+PRs="$($GH pr list --label "p: blocker / 1" --json number --jq '.[].number')"


You probably want to make sure that they also have the "postive review" label.

Definitely not. Sometimes it takes a while to find a competent reviewer.

See #36338 (comment) for @mkoeppe's opinion on this.

Without requiring "positive review" label, we can check the PR before we set it positive review.

It will influence every other PR, so I think there should be some safety measure.

Without requiring "positive review" label, we can check the PR before we set it positive review.

What do you mean? Doesn't the CI of that PR already checks the PR? Why do you need other PRs to check it?

so I think there should be some safety measure.

We already have that, namely the Triage group + common sense.

We are not putting off fire. There's no need to act immediately as soon as someone pushes a CI-fix PR and adds blocker label.

Well, it's not fire, but it's a matter of "availability of the CI services", which, if poor, leads to developer frustration (@fchapoton @tornaria) and can dramatically reduce development velocity because developers may disengage or wait until the CI is fixed again.

Let's consider the period from the release of a beta version to the release of the next beta version, currently about a week. For, say, 95% of availability of the CI, we want a CI fix to take effect within a few hours of a broken release.

We all want to fix CI failures as soon as possible and it would not take long before another one would lend second eyes to check the PR and give positive review.

This may be true for trivial fixes such as the linter failures, which can be fixed and reviewed by many people.

But for fixes to CI and build system, it hinges on the availability of a very small number of people, and time-to-positive-review can be several days -- which can easily make the availability of the CI services less than 50%.

@tobiasdiez wrote:

Sorry, but I don't understand the argument here: because two people don't like the change, we go along with the solution that one person prefers?

I know that @tobiasdiez knows this already, but I'll point out again: Our project does not hold majority votes In PR discussions.

I actually think this PR here is a perfect example: there is absolutely no reason this is tagged as a blocker, it doesn't resolve any issues with falling CIs or something similar,

This is false. This PR does resolve the issue of the failing CIs. Merging this PR is enough to fix all CI problems in the current cycle: it auto-applies the blocker PRs #36327 and #36276.

it is not tested very well (or did any of the reviewers tried to run the new macos workflow and the other changed workflows on the main repo?)

This is false, and moreover an inappropriate attack on author and reviewers.

OK. Here is my suggestion. As we can observe by looking at the labelling war below, there are conflicting opinions on which way this PR should proceed. If the issue is large and of broad interest in our community, then this situation would be resolved by a voting in sage-devel. But the current issue is a small one, and it would be ridiculous and shameful to spend a long time for endless discussions or a large-scale voting. Hence let me suggest a small voting here, as defined below:

The voting is about (a) "only blocker label" vs (b) "blocker label + positive review". The voting occurs only in this thread. The voting starts by the votes of @tobiasdiez and @mkoeppe, by which they are supposed to have vowed on accepting the voting result. The voting ends automatically when there was no more vote for the last 24 hours. When the voting ends, the author of the PR proceeds in the way of winning candidate. Please only vote with an optional simple comment in the rest of this thread.

-1 on holding majority votes in PRs.

@tobiasdiez wrote:

Sorry, but I don't understand the argument here: because two people don't like the change, we go along with the solution that one person prefers?

I know that @tobiasdiez knows this already, but I'll point out again: Our project does not hold majority votes In PR discussions.

I actually think this PR here is a perfect example: there is absolutely no reason this is tagged as a blocker, it doesn't resolve any issues with falling CIs or something similar,

This is false. This PR does resolve the issue of the failing CIs. Merging this PR is enough to fix all CI problems in the current cycle: it auto-applies the blocker PRs #36327 and #36276.

it is not tested very well (or did any of the reviewers tried to run the new macos workflow and the other changed workflows on the main repo?)

This is false, and moreover an inappropriate attack on author and reviewers.

Sadly not false...

tobiasdiez · 2023-09-27T02:29:51Z

.github/workflows/build.yml

@@ -24,9 +24,30 @@ concurrency:
  cancel-in-progress: true

 jobs:
+  get_ci_fixes:


This adds now another row in the checks under each PR, which is already a pretty crowded. Can this not be merged directly in the build workflow as you do say with conda?

No, because the container does not have a suitable version of the gh script available, and installing it is too annoying.

@mkoeppe, No response to this?

You may need to switch a different view; I responded above

https://github.com/marketplace/actions/install-gh-cli or something similar?

that one's not portable to i686, and overall I don't think this is a worthwhile change

I don't like the duplicate lines too. But that's a trivial issue, and there's no simple fix. Let's ignore it.

We are not using any i686 architecture...that's a very potential if and when argument...

We are not using any i686 architecture...that's a very potential if and when argument...

Yes, we are. The build.yml workflow accepts the container image on workflow_dispatch, and we do test 32-bit platforms.

dimpase · 2023-09-27T10:35:14Z

are we not reinventing the wheel here, by any chance?
https://github.blog/changelog/2023-07-12-pull-request-merge-queue-is-now-generally-available/

mkoeppe · 2023-09-27T16:56:44Z

are we not reinventing the wheel here, by any chance?
https://github.blog/changelog/2023-07-12-pull-request-merge-queue-is-now-generally-available/

Yes, @dimpase, I have considered many options, including Merge Queues. But moving to using Merge Queues is not actionable for the project; the release manager would have to adopt a changed workflow. As I wrote in #36338 (comment):

Yes, this PR is a practical solution. It is designed to avoid two approaches, each of which would be more elegant:

It does not create hotfix branches explicitly. Hence, there is no hotfix branch to maintain; hence there is not need for a maintainer of the hotfix branch.

It does not require communication with the release manager.

This careful design makes this PR an effective solution.

dimpase · 2023-09-27T18:31:52Z

I don't see how a merge queue with blockers (or positively reviewed blockers) is different in functionality from this PR.

mkoeppe · 2023-09-27T18:34:33Z

I don't see how a merge queue with blockers (or positively reviewed blockers) is different in functionality from this PR.

Well, Merge Queues are attached to a branch protection rule for a branch. A PR can only be merged in one branch, namely its target branch. So doing anything like this would interfere with the release manager's work.

mkoeppe · 2023-09-27T18:38:39Z

@dimpase You may want to try out merge queues with https://github.com/dimpase/primecountpy/pulls ...

dimpase · 2023-09-27T21:44:23Z

@dimpase You may want to try out merge queues with https://github.com/dimpase/primecountpy/pulls ...

I don't think it's a repo which needs them.

mkoeppe · 2023-09-27T21:47:45Z

But it's harmless to play with them there.

kwankyu · 2023-09-27T22:54:18Z

Thanks for the benevolent action, @vbraun!

sagemathgh-35373: Fix workflow "Build documentation (PDF)"    ### 📚 Description Follow-up on sagemath#35169. The container `sage-docker-fedora-31-maximal-with-targets` used for the PDF docbuild turned out to be not reliable. Here we replace it by `ubuntu-focal-standard-with-targets` and install texlive in it. We also copy over the incremental build from doc-build.yml and the method to get CI fixes from blocker tickets from sagemath#36338. This workflow is currently disabled in sagemath/sage. Example run: https://github.com/mkoeppe/sage/actions/runs/6318741659/job/17158468016     ### 📝 Checklist  - [x] The title is concise, informative, and self-explanatory. - [ ] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies  - Depends on sagemath#36338 - Depends on sagemath#36348  URL: sagemath#35373 Reported by: Matthias Köppe Reviewer(s): Dima Pasechnik

sagemathgh-36358: CI: Fix the multi-stage build in ci-linux.yml, fix conda/centos/archlinux system packages   Fixes breakage from sagemath#36338 seen in https://github.com/sagemath/sage/acti ons/runs/6332061118/job/17206153694: The 2nd stage (`...-with-targets`) does not find the container from the 1st stage (`...-with-targets-pre`) because they are keyed to the commit sha. Fixed here by keying it to the sha before merging the CI fixes. Also fixing the following failures: - `conda-forge-minimal` (as seen in https://github.com/sagemath/sage/act ions/runs/6207962004/job/16858998561); failed because the python3 depcheck packages were missing. Fixed now - check with `tox -e docker- conda-forge-minimal -- config.status` - `centos-stream-9-python3.9-minimal` (https://github.com/sagemath/sage/ actions/runs/6207962004/job/16858997494), `almalinux-9-python3.11-minimal` (https://github.com/sagemath/sage/actio ns/runs/6207962004/job/16858997663) and `-standard`; fixes sagemath#34786 - `archlinux-standard` - libgiac was missing in at least one run Also adding a few more uses of GH Action output groups for convenience. Tests running at https://github.com/mkoeppe/sage/actions/workflows/ci- linux.yml    ### 📝 Checklist     - [x] The title is concise, informative, and self-explanatory. - [x] 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 accordingly. ### ⌛ Dependencies   URL: sagemath#36358 Reported by: Matthias Köppe Reviewer(s): Dima Pasechnik

gh-35373: Fix workflow "Build documentation (PDF)"    ### 📚 Description Follow-up on #35169. The container `sage-docker-fedora-31-maximal-with-targets` used for the PDF docbuild turned out to be not reliable. Here we replace it by `ubuntu-focal-standard-with-targets` and install texlive in it. We also copy over the incremental build from doc-build.yml and the method to get CI fixes from blocker tickets from #36338. This workflow is currently disabled in sagemath/sage. Example run: https://github.com/mkoeppe/sage/actions/runs/6318741659/job/17158468016     ### 📝 Checklist  - [x] The title is concise, informative, and self-explanatory. - [ ] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies  - Depends on #36338 - Depends on #36348  URL: #35373 Reported by: Matthias Köppe Reviewer(s): Dima Pasechnik

gh-36358: CI: Fix the multi-stage build in ci-linux.yml, fix conda/centos/archlinux system packages   Fixes breakage from #36338 seen in https://github.com/sagemath/sage/acti ons/runs/6332061118/job/17206153694: The 2nd stage (`...-with-targets`) does not find the container from the 1st stage (`...-with-targets-pre`) because they are keyed to the commit sha. Fixed here by keying it to the sha before merging the CI fixes. Also fixing the following failures: - `conda-forge-minimal` (as seen in https://github.com/sagemath/sage/act ions/runs/6207962004/job/16858998561); failed because the python3 depcheck packages were missing. Fixed now - check with `tox -e docker- conda-forge-minimal -- config.status` - `centos-stream-9-python3.9-minimal` (https://github.com/sagemath/sage/ actions/runs/6207962004/job/16858997494), `almalinux-9-python3.11-minimal` (https://github.com/sagemath/sage/actio ns/runs/6207962004/job/16858997663) and `-standard`; fixes #34786 - `archlinux-standard` - libgiac was missing in at least one run Also adding a few more uses of GH Action output groups for convenience. Tests running at https://github.com/mkoeppe/sage/actions/workflows/ci- linux.yml    ### 📝 Checklist     - [x] The title is concise, informative, and self-explanatory. - [x] 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 accordingly. ### ⌛ Dependencies   URL: #36358 Reported by: Matthias Köppe Reviewer(s): Dima Pasechnik

@kwankyu

sagemathgh-36498: CI build, doc-build: Run containers explicitly, separate jobs for pyright, build, modularized tests, long tests    Running the containers explicitly, instead of using the declarative `container:` feature of GH Actions gives us more control: - we can create more space on the host if necessary; we just scraped by an out of space condition in sagemath#36473 / sagemath#36469 (comment) - we can run some operations outside of the container but in the same job; this will make the separate "Get CI fixes" jobs unnecessary, addressing the cosmetic concerns from sagemath#36338 (comment), sagemath#36349 - it enables caching between the various workflows (as first discussed in sagemath#36446). We split out static type checking with pyright into its separate workflow: - **pyright.yml**: As static checking does not need a build of the Sage library, for PRs that do not make any changes to packages, there's nothing to build, and the workflow gives a fast turnaround just after 10 minutes. For applying the CI fixes from blocker tickets, this workflow uses the technique favored in sagemath#36349. The workflow **build.yml** first launches a job: - **test-new:** It builds incrementally (using a tox-generated `Dockerfile` and https://github.com/marketplace/actions/build-and-push- docker-images) and does the quick incremental test. This completes within 10 to 20 minutes when there's no change. After this is completed, more jobs are launched: - **test-mod:** It again builds incrementally and tests a modularized distribution. Later (with more from sagemath#35095), more jobs will be added to this matrix job for other distributions. - **test-long:** It again builds incrementally and runs the long test. The workflows **doc-build.yml** and **doc-build-pdf.yml** again build incrementally and then build the documentation. The diffing code for the HTML documentation now runs in the host, not the container, which simplifies things. (To show that diffing still works, we include a small change to the Sage library.) Splitting the workflow jobs implements @kwankyu's suggestion from: - sagemath#35652 (comment) (Fixes sagemath#35814) The steps "again builds incrementally" actually use the GH Actions cache, https://docs.docker.com/build/ci/github-actions/cache/#cache- backend-api. When nothing is cached and the 3 workflows are launched in parallel, they may each build the same thing. But when there's congestion that leads to the workflows to be run serially, the 2nd and 3rd workflow will be able to use the cache from the 1st workflow. This elasticity may be helpful in reducing congestion. There is a rather small per-project limit of 10 GB for this cache, so we'll have to see how effectively caching works in practice. See https://github.com/sagemath/sage/actions/caches   ### 📝 Checklist     - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies  - Depends on sagemath#36938 (merged here) - Depends on sagemath#36951 (merged here) - Depends on sagemath#37351 (merged here) - Depends on sagemath#37750 (merged here)  URL: sagemath#36498 Reported by: Matthias Köppe Reviewer(s): Kwankyu Lee, Matthias Köppe

@kwankyu

sagemathgh-36498: CI build, doc-build: Run containers explicitly, separate jobs for pyright, build, modularized tests, long tests    Running the containers explicitly, instead of using the declarative `container:` feature of GH Actions gives us more control: - we can create more space on the host if necessary; we just scraped by an out of space condition in sagemath#36473 / sagemath#36469 (comment) - we can run some operations outside of the container but in the same job; this will make the separate "Get CI fixes" jobs unnecessary, addressing the cosmetic concerns from sagemath#36338 (comment), sagemath#36349 - it enables caching between the various workflows (as first discussed in sagemath#36446). We split out static type checking with pyright into its separate workflow: - **pyright.yml**: As static checking does not need a build of the Sage library, for PRs that do not make any changes to packages, there's nothing to build, and the workflow gives a fast turnaround just after 10 minutes. For applying the CI fixes from blocker tickets, this workflow uses the technique favored in sagemath#36349. The workflow **build.yml** first launches a job: - **test-new:** It builds incrementally (using a tox-generated `Dockerfile` and https://github.com/marketplace/actions/build-and-push- docker-images) and does the quick incremental test. This completes within 10 to 20 minutes when there's no change. After this is completed, more jobs are launched: - **test-mod:** It again builds incrementally and tests a modularized distribution. Later (with more from sagemath#35095), more jobs will be added to this matrix job for other distributions. - **test-long:** It again builds incrementally and runs the long test. The workflows **doc-build.yml** and **doc-build-pdf.yml** again build incrementally and then build the documentation. The diffing code for the HTML documentation now runs in the host, not the container, which simplifies things. (To show that diffing still works, we include a small change to the Sage library.) Splitting the workflow jobs implements @kwankyu's suggestion from: - sagemath#35652 (comment) (Fixes sagemath#35814) The steps "again builds incrementally" actually use the GH Actions cache, https://docs.docker.com/build/ci/github-actions/cache/#cache- backend-api. When nothing is cached and the 3 workflows are launched in parallel, they may each build the same thing. But when there's congestion that leads to the workflows to be run serially, the 2nd and 3rd workflow will be able to use the cache from the 1st workflow. This elasticity may be helpful in reducing congestion. There is a rather small per-project limit of 10 GB for this cache, so we'll have to see how effectively caching works in practice. See https://github.com/sagemath/sage/actions/caches   ### 📝 Checklist     - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies  - Depends on sagemath#36938 (merged here) - Depends on sagemath#36951 (merged here) - Depends on sagemath#37351 (merged here) - Depends on sagemath#37750 (merged here)  URL: sagemath#36498 Reported by: Matthias Köppe Reviewer(s): Kwankyu Lee, Matthias Köppe

@kwankyu

sagemathgh-36498: CI build, doc-build: Run containers explicitly, separate jobs for pyright, build, modularized tests, long tests    Running the containers explicitly, instead of using the declarative `container:` feature of GH Actions gives us more control: - we can create more space on the host if necessary; we just scraped by an out of space condition in sagemath#36473 / sagemath#36469 (comment) - we can run some operations outside of the container but in the same job; this will make the separate "Get CI fixes" jobs unnecessary, addressing the cosmetic concerns from sagemath#36338 (comment), sagemath#36349 - it enables caching between the various workflows (as first discussed in sagemath#36446). We split out static type checking with pyright into its separate workflow: - **pyright.yml**: As static checking does not need a build of the Sage library, for PRs that do not make any changes to packages, there's nothing to build, and the workflow gives a fast turnaround just after 10 minutes. For applying the CI fixes from blocker tickets, this workflow uses the technique favored in sagemath#36349. The workflow **build.yml** first launches a job: - **test-new:** It builds incrementally (using a tox-generated `Dockerfile` and https://github.com/marketplace/actions/build-and-push- docker-images) and does the quick incremental test. This completes within 10 to 20 minutes when there's no change. After this is completed, more jobs are launched: - **test-mod:** It again builds incrementally and tests a modularized distribution. Later (with more from sagemath#35095), more jobs will be added to this matrix job for other distributions. - **test-long:** It again builds incrementally and runs the long test. The workflows **doc-build.yml** and **doc-build-pdf.yml** again build incrementally and then build the documentation. The diffing code for the HTML documentation now runs in the host, not the container, which simplifies things. (To show that diffing still works, we include a small change to the Sage library.) Splitting the workflow jobs implements @kwankyu's suggestion from: - sagemath#35652 (comment) (Fixes sagemath#35814) The steps "again builds incrementally" actually use the GH Actions cache, https://docs.docker.com/build/ci/github-actions/cache/#cache- backend-api. When nothing is cached and the 3 workflows are launched in parallel, they may each build the same thing. But when there's congestion that leads to the workflows to be run serially, the 2nd and 3rd workflow will be able to use the cache from the 1st workflow. This elasticity may be helpful in reducing congestion. There is a rather small per-project limit of 10 GB for this cache, so we'll have to see how effectively caching works in practice. See https://github.com/sagemath/sage/actions/caches   ### 📝 Checklist     - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies  - Depends on sagemath#36938 (merged here) - Depends on sagemath#36951 (merged here) - Depends on sagemath#37351 (merged here) - Depends on sagemath#37750 (merged here) - Depends on sagemath#37277 (merged here)  URL: sagemath#36498 Reported by: Matthias Köppe Reviewer(s): Kwankyu Lee, Matthias Köppe

Matthias Koeppe added 7 commits September 25, 2023 16:22

build/pkgs/sagemath_{coxeter3,mcqd,meataxe,tdlib}: Remove bad conda.txt

52508f6

tox.ini (debian-trixie): Use IGNORE_MISSING_SYSTEM_PACKAGES=yes

0a27b65

.github/workflows/ci-macos.yml: Refactor through new reusable workflo…

4ba2b6a

…w macos.yml, update macOS, Xcode versions

.ci/merge-fixes.sh: New

9cff8ff

Use .ci/merge-fixes.sh in all workflows

a9d84a8

.ci/merge-fixes.sh: Unshallow for merge

e4025c1

build.yml, doc-build.yml: First create CI fixes as an artifact, so gh…

3949cc7

… is not needed in the container

kliem reviewed Sep 26, 2023

View reviewed changes

Matthias Koeppe added 2 commits September 26, 2023 11:10

.github/workflows/macos.yml: Remove Docker-specific upstream artifact…

8d1b661

… handling

.github/workflows/build.yml: More quiet in the new git acrobatics

21fc2b3

kliem approved these changes Sep 26, 2023

View reviewed changes

Matthias Koeppe added 2 commits September 26, 2023 14:53

Do not make empty commits

b92d9f4

.github/workflows/{build,doc-build}.yml: Use actions/upload-artifact@v3

b14ef26

tobiasdiez requested a review from vbraun September 26, 2023 22:33

dimpase approved these changes Sep 26, 2023

View reviewed changes

tobiasdiez previously requested changes Sep 27, 2023

View reviewed changes

kwankyu added s: needs work and removed s: positive review labels Sep 27, 2023

tobiasdiez removed the s: positive review label Sep 27, 2023

kwankyu added s: positive review and removed s: needs review labels Sep 27, 2023

tobiasdiez removed the s: positive review label Sep 27, 2023

vbraun merged commit bb04839 into sagemath:develop Sep 27, 2023

github-actions bot removed the s: needs review label Sep 27, 2023

tobiasdiez mentioned this pull request Sep 28, 2023

ci: improve things around auto-apply of fixes #36349

Closed

5 tasks

Uh oh!

CI: Merge open blocker PRs in all CI workflows + other improvements #36338

CI: Merge open blocker PRs in all CI workflows + other improvements #36338

Uh oh!

Conversation

mkoeppe commented Sep 25, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📝 Checklist

⌛ Dependencies

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mkoeppe Sep 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tobiasdiez commented Sep 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mkoeppe commented Sep 26, 2023

Uh oh!

kliem commented Sep 26, 2023

Uh oh!

mkoeppe commented Sep 26, 2023

Uh oh!

kliem commented Sep 26, 2023

Uh oh!

tobiasdiez commented Sep 26, 2023

Uh oh!

dimpase left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Sep 27, 2023

Uh oh!

kwankyu commented Sep 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mkoeppe Sep 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kwankyu Sep 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mkoeppe commented Sep 25, 2023 •

edited

Loading

mkoeppe Sep 26, 2023 •

edited

Loading

tobiasdiez commented Sep 26, 2023 •

edited

Loading

kwankyu commented Sep 27, 2023 •

edited

Loading

mkoeppe Sep 27, 2023 •

edited

Loading

kwankyu Sep 27, 2023 •

edited

Loading