On Beta Testing

[iceiceice]

Mac version aside, a Jenkins deployment to a GitHub repo for Linux or Windows builds would be very doable. if you didn't want to have every build deployed on every SCM change, you could set up a deploy script to run (and then we'd have nightlies!) which would make a huge difference for testers. (Seeing it's version control, you should just be able to push up the changes each night instead of sending the whole project each time).

As I pointed out on irc when we talked earlier, we currently do this with windows, as you can see from the jenkins build logs, and you can get the cross-compiled windows nightly here:

http://baldras.wesnoth.org:8080/job/Wes ... ebian7-32/

In case I wasn't clear, yes, cross-compiling should be possible. (Of course, it wouldn't be easy the first time.)

If it's possible, that's great, but to figure out how to do it we would need to have a person with access to a linux machine and a mac set it up and test it. The current OSX packager has said that he doesn't consider himself knowledgeable about compilers to the degree necessary to figure this out, all he knows how to do is click to update the Xcode project file and click the compile button. IIUC he only does this because if he didn't, then we wouldn't have an OSX release at all.

So for this to happen, we would probably need a volunteer to demonstrate that it works, start to finish. Besides this, the people who have access to and maintain jenkins-CI on the server (AI0867 and loonycyborg iiuc?) would have to sign off on it and agree to maintain it, or more likely the volunteer would have to agree to become the maintainer.

[ancestral]

Mac version aside, a Jenkins deployment to a GitHub repo for Linux or Windows builds would be very doable. if you didn't want to have every build deployed on every SCM change, you could set up a deploy script to run (and then we'd have nightlies!) which would make a huge difference for testers. (Seeing it's version control, you should just be able to push up the changes each night instead of sending the whole project each time).

As I pointed out on irc when we talked earlier, we currently do this with windows, as you can see from the jenkins build logs, and you can get the cross-compiled windows nightly here:

http://baldras.wesnoth.org:8080/job/Wes ... ebian7-32/

I guess I’m not explaining this well.

Either use a new branch or a new repo. Testers would clone it (if they haven't already). Then, every night, Jenkins pushes the last successful binary up to GitHub. So the next morning, Testers will have the new binary the next day. (Which saves them the hassle of having to build using the command line.) Plus it wouldn't be taxing bandwidth on the Jenkins server as people wouldn't download it from there; they'll just git pull and have it already — from GitHub.

(Some info here may be helpful: http://fourword.fourkitchens.com/articl ... ing-github)

[iceiceice]

I see. So basically you want this last line "cp ..." in the build log to be "scp ..." or even "git push ..." so you don't end up downloading from baldras directly.

But you know, the binary is only 25mb, much less than the ~1.8 gig you would get from just the most recent git repo revision (with no history).

I mean can't we just say "windows users, simply run `git fetch upstream`, `git checkout upstream/1.12`, then download this executable and drop it in place at the root of the repo?"

I'm not really sure but my assumption is that 25mb, at the rate that we would likely have testers downloading it, doesn't seem much different from the traffic that the add-on server gets. (I'm pretty sure this is all on the same server?)

Either use a new branch or a new repo.

If it's a branch then I guess that would mean baldras would need commit credentials to the main repo, which doesn't seem like such a great idea.

[ancestral]

But you know, the binary is only 25mb, much less than the ~1.8 gig you would get from just the most recent git repo revision (with no history).

I mean can't we just say "windows users, simply run `git fetch upstream`, `git checkout upstream/1.12`, then download this executable and drop it in place at the root of the repo?"

GitHub has pretty good Windows and Mac clients. Pushing a button to sync is far easier than typing in URLs and moving files imo, as there could be several file changes in addition to just the Wesnoth binary.

Thinking about it more, a separate GitHub repo is probably the better choice, so people don't have to download other branch changes. (Call it wesnoth-nightly-win or what-have-you.)

If it's a branch then I guess that would mean baldras would need commit credentials to the main repo, which doesn't seem like such a great idea.

Why? What's wrong? Especially if it's in its own repo, then there's zero risk.

[Pentarctagon]

But you know, the binary is only 25mb, much less than the ~1.8 gig you would get from just the most recent git repo revision (with no history).

Using the -s and -Os options reduces the size further to ~11MBs.