Mega deployment or github releases or something else?

[JJM152]

I started looking into this tonight when I had some free time. There's just an issue with using mega that I can't seem to resolve, essentially there is no way to automatically share uploaded content, which means it's more or less useless for the purpose we want.

I read through the appveyor documentation a bit more and I think perhaps it may be better to use the deployment provider for github releases.

Theoretically the way this should work is - apply a tag to the repo, then the artifacts get built and attached to a new release as a release asset (along with the source code, automatically from the repo). The description field is mandatory, so something would have to be added in there... maybe from a file in the repo.

The thing is, while this could be set up, I wonder what practical use it is because creating a release manually (and attaching a compiled twine app) is trivial. I think what we really want is actual CI and I don't think I'm keen with every commit adding a release with a binary to the releases tab.

One obvious choice would be to set up a github pages, but then I get back to being worried about violating their TOS. It appears that this is easy enough to set up even though Appveyor doesn't have a specific provider for it, see https://www.appveyor.com/docs/how-to/git-push/

So basically, I'd make a separate repo, "Queen-Builds" or something, then hook that into github pages and push to the top of that repo the build artifact (index.html) from this repo. I think that should work.

So, what do you think about this:

• Every commit, AppVeyor builds the artefact and pushes to a different repo hooked up to pages.
• We don't publish that link, it's used just for internal testing.
• Every tag version AppVeyor builds the artefact, creates a release in github, then attaches the artefact. It also uploads the file to my mega account where I can then manually share the link (this would be where people usually download it)

Better ideas?

[ezsh]

Sorry, I don't understand the problem with mega. There is a possibility to share files via a CLI tool, albeit another package is needed (megacmd instead of megatools). But we agreed the uploading scheme that does not seem require sharing individual files, because files are uploaded to a directories that can be shared, providing access to their contents.

What do I miss and why do we need to share individual files?

[JJM152]

So, first off:

because files are uploaded to a directories that can be shared, providing access to their contents.

That's true I suppose for people who are already invited to that share directory. That's not the entire scenario I envisioned. Maybe we just need to get entirely on the same page so let's back it up a bit and just focus on what I think the optimal scenarios are:

Build Release

• Tag repo with a build tag (pre-release, or release)
• Releases gets updated in github
• Artefact(s) get built, zipped and uploaded "somewhere"
• Notification goes out (someplace) where to pick them up

I didn't know there was a way to generate a share link for a file through a cli and if there is, I'd like to do that after uploading the file and then send out a notification with the share link in it. For me, this means that I can easily update any distributed links for the game on other sites with the new link. Heck, with this I could even write something to update the games IGDB entry automatically. That actually has a lot of value I think.

CI

• Commit to repo
• Artefacts get built and published to a web host
• No notification.

In a perfect world, you'd add some tests in there, at least for the javascript, but manual testing for now would still be okay.

Anyway, if you're saying that I can install a different toolset on that image and get the result I want, then I'll pick it up from there. I simply didn't know about that.

[ezsh]

That's true I suppose for people who are already invited to that share directory.

Here is the link to the directory created in my mega profile by the publishing script. You can download the file inside. At least I can do that using another browser without mega sign in.

Build Release

Publishing to github can be handled from AppVeyour. Maybe we need to extract the packaging command into its own file and run during the CI build, then publish using AppVeyour (or another CI service).

For me, this means that I can easily update any distributed links for the game on other sites with the new link.

As a user, I would be happy to get a permanent link to a web folder, where I can always download the latest or earlier release. I must have said that already, sorry.

[JJM152]

Here is the link to the directory created in my mega profile by the publishing script. You can download the file inside. At least I can do that using another browser without mega sign in.

Da fuck? Everything I am reading here says that you have to implicitly share a folder with contacts.

[ezsh]

Pardon?

[JJM152]

I'm saying the documentation in mega leads me to believe that you must implicitly share a folder to specific people.

Obviously that's not the case as I just tested it myself, but I'm just going off of what I read.

[ezsh]

OK, if that works, can we use it? If yes, we probably have to make sure that adding/removing files to/from a shared folder does not change it shareable link (would be stupid if the folder changes, but I have never checked that).

[JJM152]

nevermind I got it

[JJM152]

Hmm, still dissatisfied.

I'm logged into another session and did another build via the tag/release system here and it showed up like this:

See if you can access the file and let me know - https://mega.nz/#F!zaZBiSYY!wcH5sSiP10Lg926PnkSsWw

This stack exchange post isn't making me very hopeful.

[ezsh]

Let me try that myself, please.

[JJM152]

Found this issue in the megatools git as well https://github.com/megous/megatools/issues/54

[ezsh]

I see now. Well, this is pity.

mega-put from the megacmd package handles that just fine. Do you want me to rewrite the AppVeyour and the publishing script?

Update: just tested mega-put.

[JJM152]

Sure if you want to have a crack at it, I can probably do some testing tomorrow before I leave on vacation.

[ezsh]

OK, I'll do that in a couple of hours.

[JJM152]

Appears to be working now. Can you access the builds?

I made a minor modification so that non tag builds default to Queen-latest as the file name.

[ezsh]

I can download Queen-latest.zip.

what other variables could we pass from the events that trigger the webhook. Do regular commits pass a commit hash, etc?

https://www.appveyor.com/docs/environment-variables/

[JJM152]

Well, I guess we can consider this closed for now.