Skip to content
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

Disable broken and outdated CI #39467

Open
wants to merge 7 commits into
base: develop
Choose a base branch
from

Conversation

tobiasdiez
Copy link
Contributor

@tobiasdiez tobiasdiez commented Feb 6, 2025

Many of the CI runs after a new release are failing, for months now, see eg https://github.com/sagemath/sage/actions/runs/12979684199/job/36218126145. Some of these failures are genuine (eg a certain package cannot be built on a certain system) and some others are due to constraints of the build system (eg running out of free space). Since there is very little point in senselessly burning energy, all runs that were failing for the last releases are disabled. Once the underlying issues are fixed, they can be easily be re-enabled.

Moreover, the "minimal" runs where only a couple of systems packages are installed and most are build using sage are removed, keeping only the "maximal" where all available system packages are installed.

New test run: https://github.com/tobiasdiez/sage/actions/runs/13199372232/job/36847711005

📝 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

Copy link

github-actions bot commented Feb 6, 2025

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

@user202729
Copy link
Contributor

There's a risk of we just forget to reenable it. Is there a good way to do this dynamically (i.e. check which tests the last release fail and skip these)?

@tobiasdiez
Copy link
Contributor Author

There's a risk of we just forget to reenable it.

I'll open an issue where we can track which systems are failing, so we don't forget it. The issue tracker might actually be a more visible place in the first place as most people will not check the CI runs.

Is there a good way to do this dynamically (i.e. check which tests the last release fail and skip these)?

Not that I know.

@tobiasdiez tobiasdiez marked this pull request as ready for review February 7, 2025 12:04
@tobiasdiez tobiasdiez requested review from dimpase and kwankyu February 7, 2025 12:04
@dimpase
Copy link
Member

dimpase commented Feb 7, 2025

Great, thanks for taking care of this.

@dimpase
Copy link
Member

dimpase commented Feb 7, 2025

There's a risk of we just forget to reenable it. Is there a good way to do this dynamically (i.e. check which tests the last release fail and skip these)?

we had a heated argument at some point whether 'minimal' configurations are meaningful beyond someone's curiosity - and they are certainly the longest ones (building gcc, python, and a bunch of equally mainstream packages from sources, that's just a contribution to global warming)
I think they should be just gone.

@kwankyu
Copy link
Collaborator

kwankyu commented Feb 8, 2025

Removing things in CI may break other things elsewhere. Especially the developer guide. In particular, https://doc-release--sagemath.netlify.app/html/en/developer/portability_testing. Did you check?

The docker images created by CI linux are used by developers. The sage binder repo (https://github.com/sagemath/sage-binder-env) is using them (in particular the "minimal" image). The interactive sage doc relies on them. This PR will break the doc.

Changes affecting developers widely should be discussed or at least posted on sage-devel. This PR falls in the category.

all runs that were failing for the last releases are disabled. Once the underlying issues are fixed, they can be easily be re-enabled.

We do not remove code for temporary change. Do not invent a new protocol that code is removed to be disabled.

Improving CI is good, but the present PR is also destructive. I object to this PR.

@kwankyu kwankyu added disputed PR is waiting for community vote, see https://groups.google.com/g/sage-devel/c/IgBYUJl33SQ and removed s: positive review labels Feb 8, 2025
@dimpase
Copy link
Member

dimpase commented Feb 8, 2025

@kwankyu What exactly is broken by this PR?
Please point it out. This PR is removing CI bits which have been broken for a long time. There is nothing wrong with this.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2025

And if you think this PR needs work, please label it so, not "disputed".

@dimpase dimpase added s: needs info and removed disputed PR is waiting for community vote, see https://groups.google.com/g/sage-devel/c/IgBYUJl33SQ labels Feb 8, 2025
@user202729
Copy link
Contributor

Technically you're right in that this merely remove part of CI that has been broken by some other change made months ago (thus doesn't "in addition" break anything), and reverting this is as simple as a git revert, but I think there is a small disadvantage in deleting the code entirely (compared to e.g. just comment it out): people unfamiliar with the change, coming across the file, would have no indication that something was temporarily disabled.

I don't personally use the minimal configurations and have no strong opinion on whether they're actually useful to developers. Of course having more configurations lead to additional maintenance burden and spent computing power (such as the maintenance cost needed now to make the minimal configuration build again), the cost may not be justified by the usefulness to developers/users.

Anyway, since the intention of this PR is to temporarily disable the run until the bug is fixed, can't we just comment it out?

I mean, we're all volunteers, if anyone volunteers to fix the minimal configurations then of course that will supersede this pull request and everyone are happy [1]… but if nobody does, the feature unfortunately will remain broken.

[1] maybe except those who prefer the minimal configurations to be deleted anyway, but I think the usual workflow is deleting a feature requires 1-year deprecation period and/or announcement of some sort.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2025

One doesn't need a deprecation period to remove broken code, and minimal configurations are

  • mostly broken

  • make installation harder, especially for people who don't know better

  • increase maintenance burden (several times a month I have to tell a misguided user on sage-support or sage-devel to please install compilers and/or Python system-wide, and do not torture themselves and us with attempts to build these from source).

  • bloat the codebase of sage the distro with heaps of packages readily available either in the OS, or in a semi standard add-on such as Homebrew, or on PyPI

  • are as un-pythonic as one can imagine (no popular python project commits this sort of stupidity)

Why do we keep killing the project this way, just because few people find these minimal configs interesting or something?

@kwankyu
Copy link
Collaborator

kwankyu commented Feb 8, 2025

@kwankyu What exactly is broken by this PR? Please point it out. This PR is removing CI bits which have been broken for a long time. There is nothing wrong with this.

Did you see the section of the developer guide that I pointed out?

The removed chunks of ci-linux are responsible to push various docker images. One of the image, ubuntu-jammy-standard, is used in the CI check workflows for PRs. This PR will collapse the whole CI checks.

Other images, ubuntu-jammy-minimal-with-targets and ubuntu-jammy-minimal-with-system-packages, are used in sage-binder-env. This PR will collapse it and the interactive sage doc that is using it.

@user202729
Copy link
Contributor

user202729 commented Feb 8, 2025

Can we not escalate this, thanks.

Anyway, I think a good compromise is

  • just merge this
  • open an issue to track which systems it fails on (i.e. equivalent to saying "it is a known bug that the build fails on system X")
  • if someone comes forward with a pull request to fix it later we should incorporate it (the burden is on them to show it works well across multiple operating systems, and we may add a big red warning that tool X or package Y is better installed with operating system installer)

Do you think this is reasonable? (anyway I'm not a maintainer and would be happy with anything)

p/s. @kwankyu , I don't really completely understand what's going on, but if the particular CI has been failing for months, how come the incremental things etc. still work (this is test-new right?) Or does this PR also remove working runs?

["standard"]
docker_push_repository: ghcr.io/${{ github.repository }}/
logs_artifact: false

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this? What is broken?

# Make sure that all "standard" jobs can start simultaneously,
# so that runners are available by the time that "default" starts.
max_parallel: 50

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this? What is broken?

fi; \\
rm -rf /sage/src; \\
mv src /sage/src; \\
cd /sage && ./bootstrap && ./config.status; \\
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way what is this part supposed to do? As I read retrofit-worktree does

    echo >&2 "usage: $0 WORKTREE_NAME WORKTREE_DIRECTORY"
    echo >&2 "Ensures that the current working directory is a git repository,"
    echo >&2 "then makes WORKTREE_DIRECTORY a git worktree named WORKTREE_NAME."

but I don't understand why. Your commit would make sense if you assume the retrofit-worktree always fail (but why would it?)

max_parallel: 8

minimal:
if: ${{ success() || failure() }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this?

There are broken platforms. We may selectively turn them off until fixed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"gentoo-python3.10" is dead, as Gentoo doesn't ship python 3.10 any more (and 3.11 will soon be gone, too)

maximal-pre:
if: ${{ success() || failure() }}
needs: [minimal]
uses: ./.github/workflows/docker.yml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this?

There are broken platforms. We may selectively turn them off until fixed.


optional:
if: ${{ success() || failure() }}
needs: [maximal-pre]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this?

We may turn this off until fixed.

targets_optional: '$(echo $(export PATH=build/bin:$PATH && sage-package list :optional: --has-file "spkg-install.in|spkg-install|requirements.txt" --no-file "huge|has_nonfree_dependencies" | grep -v sagemath_doc | grep -v ^_))'

experimental:
if: ${{ success() || failure() }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this?

We may turn this off until fixed.


needs: [dist]

runs-on: ${{ matrix.os }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this also failing? I cannot find a run.

@kwankyu
Copy link
Collaborator

kwankyu commented Feb 8, 2025

Anyway, I think a good compromise is

  • just merge this
    ...
    Do you think this is reasonable?

No.

p/s. @kwankyu , I don't really completely understand what's going on, but if the particular CI has been failing for months,

CI-linux runs portability tests on supported platforms. As you can see in

https://github.com/sagemath/sage/actions/runs/12979684199

some jobs like "standard" fail for some platforms while some other jobs like "optional" fail for all patforms.

We should selectively turn them off until fixed, not remove the jobs.

how come the incremental things etc. still work (this is test-new right?)

because the "default" job running tests on ubuntu-jammy-standard succeeds, its docker image is pushed, and the incremental things are using the docker image to test PRs incrementally.

Or does this PR also remove working runs?

Yes.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2025

ubuntu-jammy-minimal-with-targets and ubuntu-jammy-minimal-with-system-packages why minimal in Binder? What's the point of building e.g. gfortran and python3 from source there?

@kwankyu
Copy link
Collaborator

kwankyu commented Feb 8, 2025

Sorry. They are irrelevant questions. The point is that those docker images have been a part of our infrastructure. Removing the infrastructure should not be done without community-wide discussion.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2025

Sorry. They are irrelevant questions. The point is that those docker images have been a part of our infrastructure. Removing the infrastructure should not be done without community-wide discussion.

No, the point it that there is no need to use these particular images. Standard images would do just as well. Please don't tell me that we must keep this minimal nonsense due to historical reasons.

@user202729
Copy link
Contributor

Sorry. They are irrelevant questions. The point is that those docker images have been a part of our infrastructure. Removing the infrastructure should not be done without community-wide discussion.

No, the point it that there is no need to use these particular images. Standard images would do just as well. Please don't tell me that we must keep this minimal nonsense due to historical reasons.

That's true, but I think that isn't in the scope of this pull request. If you want to migrate the generation of the docker images to a standard image you can open a separate one (which sounds like a good thing because the docker image is available more quickly, right?)

For this pull request, @kwankyu 's argument is we should not take advantage of the failing runs to also remove the successful runs. Whether -minimal should be removed can be discussed later.

@kwankyu
Copy link
Collaborator

kwankyu commented Feb 8, 2025

Sorry. They are irrelevant questions. The point is that those docker images have been a part of our infrastructure. Removing the infrastructure should not be done without community-wide discussion.

No, the point it that there is no need to use these particular images. Standard images would do just as well.

Please don't tell me that I chose minimal images just out of my frivolity. For Binder, creating lightest image was my priority.

For the scope of this PR: I agree that portability-test jobs that fails on all platforms should stop wasting energy until fixed. That could be achieved by adding some "if: false" conditions and commenting out and slight refactoring. Removing code is not a way to disable things temporarily.

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.

4 participants