Feat. req. Setup Actions tab for nightly builds (ags3, ags4 branches)

[necros2k7]

subj

[ivan-mogilko]

There's a link, if you go to https://www.adventuregamestudio.co.uk/site/ags/ and click on "Other Downloads & Resources >>", it will open a list of links. There's "AGS Nightly Builds" among them.

Do you mean anything else besides that?

I don't know if cirrus allows direct links to artifacts though, I was not able to get ones using their webpage, @morganwillcock ?

[rofl0r]

which branch, @necros2k7 ? there's master aka ags3 legacy, ags3--sdl2 and ags4 (next).

[morganwillcock]

I don't know if cirrus allows direct links to artifacts though, I was not able to get ones using their webpage?

You should be able to download them directly but artifacts will eventually expire so linking directly to them isn't a good idea. They would have to be uploaded somewhere else, but depending on the branch I don't think the concept of GitHub '[pre-]release' would apply.

which branch, @necros2k7 ? there's master aka ags3 legacy, ags3--sdl2 and ags4 (next).

...and what is the 'main page' ?

[necros2k7]

By main I mean https://github.com/adventuregamestudio/ags Yes ideally links should be to all latest ags3 legacy, ags3--sdl2 and ags4 (next) artifacts Kind of SCUMMVM nightly builds links

[ivan-mogilko]

There's a button in our readme which sais "builds | passing", which you can see if you scroll down on that page. Clicking on that button will direct you to the build server.

I don't know if it's possible to add links to latest builds per branch, if CI supports that then we could perhaps do that, but I'll leave this to developers who work with ci.

Alternatively, we would need to find a place either on github or other to automatically host the builds.

[necros2k7]

I thought Github Actions tab offers this functionality of setup and providing latest builds P.S. Can`t artifacts be set for long lifetime?

[ivan-mogilko]

Alright, so the idea is to have "nightly" builds (per branch?) available from some repository's "front page", and ensured to be persistent. When another nightly is built, the link / download should be replaced.

Question is whether this is possible to do on Github, and what would be this "front page". Frankly, I have no idea what "Github Actions" is, and whether it may allow this (I never used that tab).

[necros2k7]

Alright, so the idea is to have "nightly" builds (per branch?) available from some repository's "front page", and ensured to be persistent. When another nightly is built, the link / download should be replaced.

as an example: https://github.com/upx/upx/actions/runs/4334092000#:~:text=upx%2Ddevel4%2Df4c4d51%2Dwindows%2Darm64ec%2Dwin64%2Dvs2022

[ivan-mogilko]

Hmm, that's not at all the view that I'd expect from this... that's practically like embedding our CI server's table on github.

I thought the point is to have a simpler table, like a list of only the latest artifact links per branch with update date/time.

EDIT: Maybe it's a matter of creating a suitable "workflow" for this... that would display precisely what's wanted.

[morganwillcock]

GitHub Actions is a CI service, but not the one that AGS uses to build. It wouldn't be out the of the question to change it, but building with older versions of the build tools instead of tracking the latest versions makes it significantly more complicated to move. But regardless of which service is used, build artifacts will eventually expire because we do not download and store every build.

For releases and pre-releases which are created as GitHub Releases, those should be able to offered for download by implementing #616. That same page could also link to the latest CI downloads, although there is no guarantee that older builds are still there.

[ivan-mogilko]

That same page could also link to the latest CI downloads, although there is no guarantee that older builds are still there.

What I wonder, is it theoretically possible to do this:

• detect when CI finishes building for branch X;
• download selected artifacts from CI server for the last task on branch X;
• upload these artifacts as attachments to github page.
• if there are already attachments for the branch X, delete these prior to uploading new ones.

EDIT: maybe schedule attachment upload to run only once N days, for instance, to reduce the work load and traffic. In the meanwhile just link to the artifacts on CI server. (In other words: link to CI server, but once N days backup latest as attachments if no new build was run since)

[morganwillcock]

Theoretically, yes, although I'm not sure whether the GitHub Release metadata would make sense if the artifacts are being continually switched out. There is also no measure of how usable any of thoses builds are; potentially a working build gets replaced by a problematic one.

[ivan-mogilko]

Theoretically, yes, although I'm not sure whether the GitHub Release metadata would make sense if the artifacts are being continually switched out. There is also no measure of how usable any of thoses builds are; potentially a working build gets replaced by a problematic one.

Ah, but I am not speaking of changing the Release, but generating some kind of page based on CI results. I don't know all available options there, so I am theorizing. For example, we have a manual uploaded to https://adventuregamestudio.github.io/ags-manual/. May we have another page with similar parent address, and host these links / attachments there?

EDIT: hmm, maybe this is what you are speaking about here. (not sure)

[morganwillcock]

For example, we have a manual uploaded to https://adventuregamestudio.github.io/ags-manual/

I don't think this hosting is intended for distributing binaries. There are transfer limits and excessive use would probably lead to the service being disabled. The files sizes wouldn't be large but someone could define a package that starts downloading builds from here.

EDIT: hmm, maybe this is what you are speaking about https://github.com/adventuregamestudio/ags/issues/616#issuecomment-1493304407. (not sure)

What I describe there wouldn't host the binaries to make them available to download, it just provides links to where they are already hosted. The slightly fancier version uses the GitHub API to query GitHub Release metadata and build a more descriptive page, for example, the link to the latest release could list the version number instead of just saying "latest release". It could also list that latest pre-release because there is metadata that indicates the pre-release status of a release.

[ericoporto]

I have been thinking about this in the context of having whatever is the latest successful build so it can be used in a possible test game repository - see #2236 .

I had the following ideas to host "nightly" builds (I actually think it makes more sense to just be the latest successful binary from the master branch, and maybe ags4 branch too, similar to comment here).

• create an arbitrary release in GitHub named TIP, UNTESTED, or whatever and just have the CI automatically push there for the respective branches, overwriting/removing whatever it was previously stored there.

  • found a GitHub Action https://github.com/marketplace/actions/deploy-nightly, it appears it also supports pushing to a release in a different repository (if we don't want to have it show up in the releases in this repository!)

• Push to Cloudsmith, but in the same sense directly from CI

• Push to some file hosting service like google drive (this is tricky because I can't figure it out if this is ok in their terms of service)

  • found a GitHub Action for this

• Get it directly from CirrusCI, and then just write somewhere explaining how to get it from there or talk with CirrusCI if such feature would make sense

• Saw a repository where someone used a single commit repository that gets constantly force pushed here

• The other approach I saw is to have an entire repository for nightlies with a lot of releases - see https://github.com/citra-emu/citra-nightly - but we would do it slightly different to avoid having the CirrusCI running twice for the same commit, by just pushing the binaries to there directly. The repository could have a workflow that run once per day and cleans up releases that are 101th or more.

  • with this, for recent builds, we would be able to install by a specific commit hash, which can be helpful to bisect in recent changes.

[ericoporto]

Made a question on the forums and got again the idea of a GitHub release that gets overwritten

https://github.com/orgs/community/discussions/77002

I updated the previous comment with additional alternatives.