QVM: Fix bitrot and add CI. #350
Conversation
|
Not sure how you want to do the CI. Would be nice if ktx also produced GH downloads for all builds, PRs and all, also in fork repos. It's free and convenient. Example of this running can be found here: https://flagzone.nittionio.nu/ (dev-tools -> application -> clear site data if it b0rks due to stale cache). Ext functions can be verified by dropping a map in the browser with alpha for example, this will launch that map with ktx active. |
|
if you're logged in you can download the artifacts from the action. |
|
yeah, but I'm thinking of this |
|
the snapshots get pushed, but yeah definitely the targets one should be everything, on ezquake it's: on: [push, pull_request, workflow_dispatch] |
|
Example of extension syscall use, Open https://flagzone.nittionio.nu, shift+ESC for console, /rctf3_b2 to preload map into browser, ESC to menu, then new multiplayer game and /rctf3_b2 to load that map with ktx qvm ... doesn't properly load the server config atm so /exec ftesrv.cfg and /rctf3_b2 again to fully load ktx, walk off an edge a few times to get a good spawn as I don't seem to have ctf+hook enabled there and then you should be able to walk to place of screenshots. |
|
the other problem is just that we don't have an upload artifact in the target one (or the others, though they have a different purpose anyway). i was going to combine all of them into one and just have different logic paths as right now we're doing the same work multiple times but have yet to get to it. |
|
If you don't have time to integrate the CI changes properly in the other builds feel free to suggest how you want it done and I'll fix it. Would be great if the bitrot could be stopped once and for all before more comes creeping in. |
|
the goal would be to have a single workflow that always runs the logic in the current build-target.yml (but then uploads those as artifacts) and then just like the other separate steps currently have push those as snapshots if it's a push on qw-group/ktx and do a release with them if it's a release. i was going to reorganize it so there was one main file with the logic and three separate ones to be included with the actual steps, but all in one file would also be just fine as once it's deduplicated it really won't be much longer than any one of those files currently (and we'll only be building the once). testing it all by using the fork's information for the release part (and even the snapshot stuff, though it'll end up failing of course) should be simple enough, there'll just have to be storing the assets for use in the other stages and renaming etc to make it all come out the way it currently does, but definitely doable. |
|
|
|
that's exactly what i'm saying, the artifacts are only created for one of the pipelines right now and not reused- they should be created regardless and then reused depending on X for either pushing snapshots and/or release instead of rebuilding things. we do want a place for the snapshot stuff though and not just do drafts/releases for every single build, that doesn't mean there shouldn't be artifacts attached to the build though. |
|
I guess the scp stuff could remain. I'll hack up something that works with the github release flow, and that could also copy the release artifacts elsewhere. Realized I can tag to my heart's content in my fork and try things out :) The use of the word "draft" is not "draft release" but just the github phrasing of generating release notes that the release person can adapt, but you get a nice list of changes in the editor for free. |
|
it's actually pretty simple, we've just got it all divided up because it was done multiple times- always do the build creating artifacts, then only do the snapshot push of those artifacts (fiddled with for naming etc) if it's the right repo/branch, and only do the push of the artifacts to release on release/published. that's fine, that'd just mean you'd always do "that" part regardless of published i suppose. |
|
Almost done now, releases end up at your equivalence to: https://github.com/qw-ctf/ktx/releases ...like other GitHub projects. On that page you see a 'Draft a new release' (or if you're repo owner at least) that gives you this: After entering a new release you generate release notes that will auto-populate based on pull requests merged since last release. This will trigger the build including the upload job that will attach release artifacts to the release, as well as upload to builds.quakeworld.nu. Here's the current incarnation: Think I just need to place the final Sample run: |
|
i haven't looked at it yet but does it push a snapshot when it's merged into master on qw-group or after a release is tagged? |
|
When the |
dsvensson
force-pushed
the
qvm
branch
3 times, most recently
from
6506d97
to
4004504
Compare
|
Verified that https://builds.quakeworld.nu/ktx/snapshots/ is populated correctly by temporarily allowing uploads of branch Don't think there's any need to test release path specifically as it uses the same code. Here's what it looks like when building in my branch where it just echoes the result: ...which also attached the artifacts to the GH release: |
|
looks good to me |
No description provided.