Skip to content

Replace ci-linux-incremental by ci-linux #40448

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

tobiasdiez
Copy link
Contributor

@tobiasdiez tobiasdiez commented Jul 19, 2025

The incremental runs are supposed to test package updates - however, exactly in those situations, they are not working since the rebuilt sagelib is not linking correctly against the new versions. For example, in the flint update #40259, we get

[sagemath_doc_html-none] [spkg-install] from sage.rings import complex_interval, integer
[sagemath_doc_html-none] [spkg-install] ImportError: libflint.so.20: cannot open shared object file: No such file or directory

https://github.com/sagemath/sage/actions/runs/15979364834/job/45070073007?pr=40259#step:11:4686

For this reason, the incremental runs are replaced here by the build-from-zero runs. Those are a bit slower but more reliable.

📝 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.

⌛ Dependencies

@dimpase
Copy link
Member

dimpase commented Jul 19, 2025

a package update might require rebuilding of its consumers. Doesn't meson deal with it automatically?

a build from "zero" is an overkill.

@tobiasdiez
Copy link
Contributor Author

I think meson is not able to this either: #40307. But maybe it does work if you reconfigure meson.

@user202729
Copy link
Contributor

user202729 commented Jul 19, 2025

Not quite. These failures correctly reveals failures to correctly track dependency version and rebuild corresponding files.

If we stop testing this, we're theoretically telling the user "if you git pull and the build fails, wipe the build directory and rebuild everything again is the only supported solution".

… which is what we are practically telling the user anyway (since so far nobody has time to fix the dependency tracking, e.g. not @vbraun in this specific linked pull request, or in a previous case, the libsingular 4.4.1 pull request)

Just to double check, test-long on each pull request still build incrementally right? (you may want to open a pull request on your repository and check test-long takes reasonable time)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants