Add release workflow

[Kenzzer]

No description provided.

[Kenzzer]

Welp upload went through but @asherkin you'll have to tell me where they ended up lol. It certainly isn't at builds.limetech.io/?test nor builds.limetech.io/?p=accelerator

[Kenzzer]

@sapphonie do not merge this until situation above is solved, because I gotta add few more files to the workflow but I need to confirm upload is working first.

[asherkin]

It made it!

Not displayed on the page as the filename doesn't match the expected format - no incrementing ID for sorting builds with the same version number. I can get the regex it uses later, but matching the format of the existing git ones is probably easiest.

EDIT: /(?P<project>[\w-]*)(-(?P<version>[\w.\-]*))?-(hg|git)(?P<build>[\d]*)(-(?P<hash>[a-fA-F\d]*))?-(?P<platform>linux|mac|windows)\..*/

Can make that optional, but think it's needed.

[Kenzzer]

Ah yes! I forgot the git rev count tag that's where it failed, fixing that right now.

[asherkin]

I'm guessing once added properly this'll never be uploading from a PR, but FWIW there's a branch param for non-master builds to stop them getting interleaved together (as the rev count only makes sense per-upstream-branch).

[Kenzzer]

Okay well there's a mistake I zip both platform as "window" accelerator-2.6.0-git171-5c18c00-windows.zip hopefully that's why it didn't show up, otherwise this should match the provided regex.

[Kenzzer]

This should be it ?

Begin upload...
Uploading accelerator-2.6.0-git172-10d51fc-windows.zip
Uploading accelerator-2.6.0-git172-10d51fc-linux.zip
Upload successful!

Unsure why the builds still don't show up.

[Kenzzer]

I'm guessing once added properly this'll never be uploading from a PR, but FWIW there's a branch param for non-master builds to stop them getting interleaved together (as the rev count only makes sense per-upstream-branch).

Ah this comment got eaten while I was replying to the PR, my apologies I didn't mean to ignore. Yes I plan on restricting the upload script to push on master directly, but I'll also add the branch param just in case :)

[asherkin]

I see all the recent ones with ?test passed.

[Kenzzer]

I see all the recent ones with ?test passed.

Oh right, that's where they went oops I forgot! I'll add the branch param then

[Kenzzer]

New uploads succeeded but don't show up I assume that's because of the branch name check, which means everything's good ? I'm going to switch off release from PR workflow.

[asherkin]

That's "worked", but the branch was apparently just called "40"?

[Kenzzer]

That's "worked", but the branch was apparently just called "40"?

Okay yeah that's wrong lol, github actions env variables are hard to understand. Time to investigate

[asherkin]

Turns out it was actually "40/merge", which has rather confused it - not what's expected either way though!

I'll fix it up at some point to turn slashes into hyphens or something though, just in case it is actually expected here.

[asherkin]

@Kenzzer Actually, I suspect that is the correct branch name, and what we'd want in the case of real test builds from PRs, so this probably is good to go!

[Kenzzer]

For paranoia sake I'll add quotation marks around each query param just to ensure no weird parsing can happen. We should be getting "release_ci" though, I suspect it replaced it with "40/merge" because of this PR. I think if I tinker a bit with the triggers I can get "release_ci" to show up once more.

[Kenzzer]

@Kenzzer Actually, I suspect that is the correct branch name, and what we'd want in the case of real test builds from PRs, so this probably is good to go!

Oh well same thoughts haha. I'll run one more quick test with the release CI if that's okay

[Kenzzer]

We should have release_ci this time (I should have added a print tbh).

We must basically be careful when testing release.yml, we must edit the on.push trigger and not on.pull_requests as it will populate the ref env variable with that PR naming.

[sapphonie]

will this not push random untrusted prs to limetech as written?

[Kenzzer]

will this not push random untrusted prs to limetech as written?

Thankfully no, secrets are disabled across forks even if somebody gets the bright idea to disable all the workflows/write their own to print secrets github won't allow it, a maintainer will have to approve the workflows.

Secrets are only shared with branches made on the same repo, so basically only you and I can do something nasty with the upload password.

[sapphonie]

nm;

https://github.com/asherkin/accelerator/pull/40/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R6

also ty for the clarification regarding secrets, makes sense

[Kenzzer]

Do not worry if you see 9 jobs that's normal.

There's 4 jobs (Release) running for this branch release_ci and only this branch (and master ofc)

There's 5 jobs (Pull request) running for all pull requests to master.

So if @asherkin greenlights this, we can merge without further modifications to the workflow files.

[Kenzzer]

Given the logs, my suspicions were correct

Begin upload for branch (release_ci)
Uploading accelerator-2.6.0-git175-af33953-windows.zip
Uploading accelerator-2.6.0-git175-af33953-linux.zip
Upload successful!

One simply has to be careful in how the workflow file is invoked; i.e must be limited to (push)

[Kenzzer]

The "cool" thing in the way I made this is that we can add any amount of branches we want to the release workflow.

name: Release

on:
  workflow_dispatch:
  push:
    branches: [ master, release_ci ]

This will make any future dev easier, rather than having "if"(s) everywhere in the yml file and getting confused.

That also takes out the "release logic" out of the "build logic" keeping every yml file straight forward.

[asherkin]

Getting release_ci now, but the quotes are coming in the values themselves, so that's quite broken.

[Kenzzer]

Hmm gonna try %22, if it solves nothing then quotation less it is

[asherkin]

Hmm gonna try %22, if it solves nothing then quotation less it is

You don't want that - encoding them would guarantee them getting to the server, and they already are!

[asherkin]

https://builds.limetech.io/?p=accelerator&b=release_ci&test 🎉

[sapphonie]

okay yay 💜

[asherkin]

When I'm home and remember (lol), I'll swap the test password for the real one.

[Kenzzer]

👀 ?

[Kenzzer]

Hopefully this is just a sorting issue and not a bug. I just merged the PR #41 and created commit 3ed1266 and the subsequent test release build isn't at the top builds.limetech.io. Instead 2.6.0-10d51fc remains the "latest" build, even though it should be 2.6.0-3ed1266.

[Kenzzer]

Oh... I think I see the problem, this is probably linked to the revision tag. The wrong latest build is tagged with git172 but the real latest build is git162.

Okay nevermind then, this is just an unfortunate side effect of when we tested the CI. This issue won't appear on the real build page.

[asherkin]

When I'm home and remember (lol), I'll swap the test password for the real one.

It has been done.