Decide on scheduled-daily

[stappersg]

Please make a decision on the github action scheduled-daily.

Either fix the daily scheduled CI actions or simply disable them.

Current state seems to be "we know it is broken and we don't care" (OK, "we know it is broken and everything else in the cloud-init project is way more important"). The signal of we know it is broken is harmful for this cool project (emitting we don't care is not cool).

[TheRealFalcon]

@stappersg , is this negatively affecting you? If so, can you explain how?

Most of our daily actions exist precisely because we don't want them to be "voting" actions for per-PR CI, but their failure still provides a signal that we'll want to fix eventually. Why do you see this as a problem?

[stappersg]

On Mon, Dec 16, 2024 at 01:52:00PM -0800, James Falcon wrote: @stappersg , is this negatively affecting you?

} @stappersg , is this negatively affecting you? [Y/N] Yes

If so, can you explain how?

An attempt follows

Most of our daily actions exist precisely because we don't want them to be "voting" actions for per-PR CI, but their failure still provides a signal that we'll want to fix eventually. Why do you see this as a problem?

The problem I see is "We don't care". That indifference hurts me. I, a sysadmin, do use cloud-init. I want to know it better. So did "a github.com fork". Got since that day every day build failure from github CI service. (Most likely all other "forkers" get those daily build failure messages.) After seeing the build failures long enough I filed #3620 (comment) Follow-up was #5867 (merged) Next build failure got exposed. I examed / research it, had to file #5869 It got marked "good first issue". (And this part-time Python programmer got scared.) Seen several more days of build failures from "scheduled daily". Feeling bad of bailing out to silence github action, tried a different approach with #5884 If merged it would have helped all other "forkers". But the merge request got rejected with "should be a straightforward fix". That was on 2024-11-18. A fat three weeks of daily reminders on build failures from `scheduled-daily` was this issue opent. Here we are now. Please decide on `scheduled-daily`. Both "disable" and "fix" stop emitting "All other things in cloud-init project are more important as good daily routine". Groeten Geert Stappers -- Silence is hard to parse

[holmanb]

Most of our daily actions exist precisely because we don't want them
to be "voting" actions for per-PR CI, but their failure still provides
a signal that we'll want to fix eventually.
Why do you see this as a problem?

The problem I see is "We don't care". That indifference hurts me.

@stappersg Excuse me?

If merged it would have helped all other "forkers".

........... and in doing that it would have removed a valuable signal that I use to help maintain this project. Why would you think that disabling these tests for the whole project so that you don't get notifications on your personal fork is the best solution?

Please decide on scheduled-daily. Both "disable" and "fix" stop
emitting "All other things in cloud-init project are more important as
good daily routine".

This test failure signal allows me to track test failures that are impossible or unreasonable for us to fix immediately. Right now I'm looking forward to rpds-py gaining support for Python 3.14, which is probably still blocked by Py03 gaining Python 3.14 support (last time I checked). As soon as releases of these projects that support 3.14 are published to PyPI the 3.14-dev test will either a) reveal further dependencies that need to gain 3.14 support or b) give me some of the information required to add support to 3.14 to cloud-init. This failing test means that I don't really need to track the releases of every cloud-init dependency.

If you don't want the failure notifications, then go disable them yourself. I haven't tested that it works myself, but typing "github actions how to not run scheduled in fork" into a search engine and clicking on the top hit took approximately 5 seconds. Why didn't you start by trying that yourself?

Here we are now.

Like I suggested before, you are free to propose a PR that resolves the issue. But a proposal that makes it more difficult for cloud-init's developers to deliver quality software is unlikely to be accepted. I'm happy to merge a change that disables the test run in downstream forks, but this still isn't a personal priority for me.

@stappersg If you are looking for ways to contribute, this PR fixes the tip-mypy failures (which I wouldn't have known about if I had merged your PR). It also adds much stronger type checking to cloud-init. Reviewing code is a great way to learn how to contribute to open source and how to use a new programming language. Your review would be greatly appreciated.