search

crystal-lang / install-crystal

GitHub Action: Install Crystal programming language
https://crystal-lang.github.io/install-crystal/configurator.html
MIT License
68 stars 8 forks source link

Problems with scheduled builds? #36

Open xendk opened 6 months ago

xendk commented 6 months ago

The configurator suggests scheduled builds for libraries, and a lot of shards seems to be doing this.

But it seems that GitHub might have a bug in the scheduler handling. I got the suspicion on naqvis/crystal-vips and after a lot of digging through repos trying to find someone with the same prerequisites, I found hugopl/pango.cr which exhibit the same symptoms.

It seems that if GitHub disables the scheduled workflow due to repository inactivity, it doesn't just disable the scheduled run of the workflow, but the entire workflow, on push, pull_request, the works.

The scheduled workflow on crystal-vips was disabled last month. Looking at the history, the fixed memory usage issue from ten months ago ran both workflows in the repository, but the Merge pull request #6 from two weeks ago only ran one.

Similarly, the workflow on pango.cr was disabled 7 months ago, and the Release v0.2.0. commit from last year ran it, while the Release v0.3.0. from 5 months ago, didn't run anything.

This isn't a problem for some ecosystems where code churn is high, but it is for Crystal, where code has a longer shelf life. And it seems that it's an issue likely to be missed by the maintainers (actions failing to run is very easy to overlook).

I've created a ticket at https://support.github.com/contact/bug-report, but I fear it might be by design, so install-crystal might want to take this into consideration.

Blacksmoke16 commented 6 months ago

AFAIK it's basically up to the owner to re-enable CI when/if it gets disabled :/.

oprypin commented 6 months ago

I haven't observed this actual issue but I can believe that it's true. But yes, what can we do... GitHub simply has chronic issues that will never be solved. Let me take this opportunity to rant. These are the chronic issues that come to mind off the top of my head:

  1. I was so annoyed about one particular issue that one day I created https://nightly.link/ -- enough said... But at the end of the day, the best I can do is hope for this to spread by word of mouth and that people trust my website in order to solve this issue... which actually in some cases I have asked people to not trust my website for their production needs but they did anyway.

  2. This issue, I guess? I was really annoyed by disabled jobs but I didn't check whether it disables everything like described here. In fact, for my own repos, I have also come up with a solution. Use GitHub Actions to set up a periodic job that prevents GitHub from periodically disabling GitHub Actions.............. https://github.com/oprypin/reenable-gha But once again, what could I possibly do to popularize this...

  3. Every GitHub repository has the setting "Fork pull request workflows from outside collaborators"->"Require approval for first-time contributors" which was made to save GitHub's resources from cryptominers. But there's also the setting "Require approval for first-time contributors who are new to GitHub " which would also clearly solve that and would be better for repository owners in every single case. So every single repository owner whenever creating a repository should set this setting, but uhhh.. let's start an awareness campaign I guess?

  4. If GitHub actually cares about its computational resources, why the heck does every Action run twice when a pull request is made? - once for the "pull request" action and once for the "push" action. Surely they could just deduplicate these. But instead every owner needs to come up with a different solution - and all of them wrong! The particularly annoying case is when people disable testing for the "push" action entirely, and then in order to run their tests, I need to either create an actual pull request (which I may not be confident about yet) OR also accompany my commit with an edit than re-enables testing for the "push" action.

xendk commented 6 months ago

But yes, what can we do

Option 1: Don't suggest schedule. No fun, we'd really like to have it on libraries.

Option 2: Suggest two workflows, one for push/pull_request and one scheduled. The scheduled one could just trigger the other. Won't save us from losing the scheduled workflow, but at least it won't take the push/pull_request workflow down with it.

Option 3: ? Anything I've not thought of?

Or, nothing of course. I like option two, in order to limit the damage as much as is possible.

straight-shoota commented 6 months ago

I really don't think there's anything we can reasonably do here. This is just an action that works in GitHub's actions environment with all it's intricacies.

We could theoretically consider suggesting a workaround such as having two workflows where the scheduled one just triggers the other. But I think that's too much complexity and has nothing to do with this action specifically. It's a general workaround for a GitHub issue.

xendk commented 6 months ago

Answer from GitHub is, unsuprisingly, "expected behaviour", and they then suggest the solution from option 2...

But I think that's too much complexity and has nothing to do with this action specifically. It's a general workaround for a GitHub issue.

You'll have to unpack that for me. Working around a GitHub issue has nothing to do with a GitHub action?

I've seen projects where bugs snug onto main because of this "expected behaviour", and the workaround is, if unpretty, not horrific, so why not go with it?

straight-shoota commented 5 months ago

Well like I said, this is nothing specific about this particular action. So I wouldn't know what we would could possibly do in this action's context. The configuration generator is intended to generate a basic configuration with parameters for this action. I don't think it should be burdened with additional complexity that's not directly related to using this action.

xendk commented 5 months ago

Well like I said, this is nothing specific about this particular action.

Well, no, but it's an issue that affects the users of this action. Would be nice if GitHub would fix the issue, but apparently not.

So I wouldn't know what we would could possibly do in this action's context.

Not suggest a configuration that might cause some to shoot themselves in the foot? If not suggesting the workaround, then maybe inserting a comment mentioning that disabled workflows is a thing?

I assume that most people will use the configurator, because, who really wants to write actions? So I think it should deliver the most safe configuration.