Pushes on my fork of SDL now trigger the build actions about sdl HOT 9 CLOSED

You mean create a daily or weekly tag that we run special build + upload GitHub actions on? That seems entirely reasonable. I don't know that we want to litter the tag list with hundreds of daily tags, I think once the ABI is stabilized the monthly point releases will serve as the useful rolling release point. I don't think we need to build artifacts at any point except official releases.

I'd leave it as is. The release artifacts (created by build-scripts/build-release.py) are different from the artifacts created by the github actions. This will lead to confusion. When people ask about a recent build, it's easy to refer to the github action artifacts.

from sdl.

Triggering a build on pushes and pull requests, that was also the behavior before merging all workflows.
We have never limited the workflows to only run on libsdl-org/SDL.

Though, I see a bug in the setup-loongarch64 action, causing builds on forks to fail if they have no previous cache.

from sdl.

Triggering a build on pushes and pull requests, that was also the behavior before merging all workflows.
We have never limited the workflows to only run on libsdl-org/SDL.

Then, probably GitHub itself did limit the workflows:

• As it stands I have only two workflows in the Actions history of my fork, both triggered today : https://github.com/Dragon-Baroque/SDL/actions. None of my past pushes did trigger the workflows.
• Moreover the Pull Request #10323 I submitted last week triggered the workflows, but they show in libsdl-org/SDL not in Dragon-Baroque/SDL.

from sdl.

I don't know exactly how GitHub decides it needs to run the actions.
Sometimes you need to explicitly enable it on forks, and sometimes it starts out of the box.

loongarch64 is fixed in 446c05a

from sdl.

Let's change it so we don't upload build artifacts during the normal build process (aside from minidumps for failures). Not only do we not want this for workflows running on other repos, but it's a waste of space given the number of commits we have.

Instead let's set up a nightly workflow that uploads artifacts and set up a web page that points at them so people can go download the latest builds?

from sdl.

I have just aligned the Settings -> Actions of my SDL fork to Disable all actions ( like in my Exult fork ) - it was Allow all actions and reusable workflows. This way, only Pull Requests to libsdl-org/SDL now trigger the builds.

I cannot understand, though, why I have not triggered any actions prior to this morning.

from sdl.

Let's change it so we don't upload build artifacts during the normal build process (aside from minidumps for failures). Not only do we not want this for workflows running on other repos, but it's a waste of space given the number of commits we have.

1ef3263 makes it such that only the libsdl-org repo will upload artifacts, unless you add [sdl-ci-artifact] to your commit message (or the tests fail).

I think running ci on forks remains useful. You want some quality control on pull requests before people create a pull request. This has been valuable for me.
Or we can limit the number of jobs that run in forks, and only run the full test suite on the libsdl-org repo?

Instead let's set up a nightly workflow that uploads artifacts and set up a web page that points at them so people can go download the latest builds?

GitHub's flow for this is creating a rolling release.
Or we can upload to an external location (git repo, sftp, ...), and link to these files.

from sdl.

1ef3263 makes it such that only the libsdl-org repo will upload artifacts, unless you add [sdl-ci-artifact] to your commit message (or the tests fail).

I think running ci on forks remains useful. You want some quality control on pull requests before people create a pull request. This has been valuable for me.

That's perfect, thank you. Running CI on forks is definitely still useful, we just don't want them uploading build artifacts.

GitHub's flow for this is creating a rolling release. Or we can upload to an external location (git repo, sftp, ...), and link to these files.

You mean create a daily or weekly tag that we run special build + upload GitHub actions on? That seems entirely reasonable. I don't know that we want to litter the tag list with hundreds of daily tags, I think once the ABI is stabilized the monthly point releases will serve as the useful rolling release point. I don't think we need to build artifacts at any point except official releases.

from sdl.

Closing this issue. We still want ci to run on forks.

from sdl.