.github/workflows: disable scheduled cron jobs on forks

[Animeshz]

Testing the changes

• I tested the changes in this PR: briefly

Donot runs the cron-jobs of stale.yml and cycles.yml outside the void-linux repository-owner.

[Chocimier]

Ideally this would be opt-in with some metadata on repository, but there isn't any nice api.
The best, secret context based on which steps can be skipped, is rather ugly.

@dmarto, what do you not like about this?

[dmarto]

You can stop all actions from the settings of your fork (if you don't want them), while if you want to keep them, you will have to maintain a commit that undoes that. I for one, want to keep the cycle action in my fork, as I do use my master branch for personal packages.

And in general, I am not a fan of embedding such "code actions" i.e the code shouldn't care in which repo it is or who is the owner of the repo. At least in my mind, when I fork something I expect 1:1. (off-topic, I bet some may will find it fun to use an action that deletes commit if inside forks - DRM by GithubAction (trademark pending))

Anyway, if the larger consensus is that this is better, I won't be mad or sad; I will simply revert it for myself.

P.S

if: github.repository_owner == 'void-linux' || github.event_name != 'schedule'

is a more clear version (disclaimer, not tested).

---

EDIT

For the stale workflow, it does make sense to have it disabled; and there for sure isn't any use inside forks.

On another note, most existing forks will probably never get this change; as most people fork and rarely update (and push) master, so if the reason is saving resources for GitHub, it is not a good reason.

[Animeshz]

You can stop all actions from the settings of your fork (if you don't want them), while if you want to keep them, you will have to maintain a commit that undoes that

I mean you have a manual workflow dispatch trigger which should 'just work' in case you want it to... I just prefer not to run the scheduled cron jobs on all the possible forks which may not expect it to run.

I for one, want to keep the cycle action in my fork, as I do use my master branch for personal packages.

Its also better to have a seperate repository for personal packages (not yet reviewed, or some not even acceptable - e.g. packages that don't tag them as versions), because seperate repository will give a proper overview what packages have been added, and you can easily track their updates if you want to, and add custom actions.

most existing forks will probably never get this change;

Probably right but change for good always have a positive impact overall

[classabbyamp]

Its also better to have a seperate repository for personal packages

the way you do this will not work for anything that provides shlibs used by other packages, because of how common/shlibs and xbps(-src) shlib handling works.

fwiw I just keep packages that aren't submitted to the repos on other branches of my fork, rebasing them as needed.

[Animeshz]

Seems interesting, I'd probably put a copy of shlib diff on the repo. I still don't think personal packages should be next to official packages, its more hard to deal with later on (e.g. version bumps).

[0x5c]

I still don't think personal packages should be next to official packages, its more hard to deal with later on (e.g. version bumps).

As someone who has a number of custom packages, my experience definitely doesn't reflect that. Custom packages live on separate branches (one per package, group of packages when some depend on others), and doing revision/version bumps only requires rebasing from the master branch. The custom packages don't affect normal packaging operations either.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.