Non-core contributed modules

adding Eloy, Anthony

Eloy - Is it possible to get this script automatically generating packages on download.moodle.org? - not added as a link on the download.moodle.org page yet (I'd like to get those dependencies sorted first before public release) - but when we have the packages being automatically generated, I can submit it to the Web Gallery - and hopefully get some direction from them regarding linking up the dependencies!
it's currently here:
http://cvs.moodle.org/contrib/tools/m4wpi_builder

Anthony - can you please add a new Item in the Contrib tracker for this too?

Thanks!

btw - If you're running an IIS 7 test box, I can e-mail through a package generated by this installer for testing if that would help!

Dan - I would be happy to add a component in the tracker. Might you suggest a name. Tool: Windows Installer or something along those lines? Peace - Anthony

thanks Anthony - maybe "Windows Web Platform Installer" ?

Dan - I've created the component Tool: Windows Web Platform Installer and set you as the component lead. Peace - Anthony

Eloy, this looks pretty cool. Can you add it to download.moodle.org to generate these after the other windows installer?

if you make it so the scripts are run straight out of a CVS checkout then changes to those build scripts would automatically update the binaries on download.moodle.org!

I'm looking forward to seeing us on http://www.microsoft.com/web/gallery/ !

Thanks for all that great work, Dan!

Thanks for pinging here (I had this completely lost).

I've installed and executed the stuff and right now there is one preliminary version available to download at:

http://download.moodle.org/download.php/windows_wpi/MoodleWindowsWpi-latest-19.zip

We can provide also one directdownload.php script in case it's necessary, in order to be able to account downloads.

In any case, I'm planning to introduce some minor modifications to the build.sh scripts (windows and wpi) in order to be able to allow them to be invoked from other scripts (where the conf will reside).

This will allow us to have one unique build.sh (straight from CVS as suggested by Martin), executed by multiple build_XX.sh scripts (where configuration happen). Right now it's impossible to use build.sh straight from CVS.

Ciao

About the directdownload.php script, Martin, there is already one bug pointing to it: MDLSITE-683 Plz, confirm.

Ciao

Thanks Eloy - that's great! - we will need some form of directdownload without a splash screen as it will interfere with the web gallery installer. - but this is enough for me to progress further with MS - thanks!

Hi Dan,

http://download.moodle.org/download.php/direct/windows_wpi/MoodleWindowsWpi-latest-19.zip

should do the trick!

I'm going to change a bit the wpi scripts as commented above to allow external configuration. Ciao

sounds great! - thanks Eloy!

Done, now config is defined out from build.sh

Right now Wpi packages will be updated each wednesday (corresponding with weeklies).

Note that I'm building both the 19_STABLE and HEAD versions, with HEAD available at:

http://download.moodle.org/download.php/direct/windows_wpi/MoodleWindowsWpi-latest.zip

(I've built it in "blind" mode, so I don't know if it works or no)

Martin FYI, it's a new /opt/bin/moodle-makewindows_wpipackages, executed from /opt/bin/moodle in a standard way, after building "normal" windows packages.

Resolving this as fixed. Thanks for the initiative Dan! B-)

Thanks Eloy - we're almost there thanks!

We need to provide an md5 hash for every build to MS and I've just found out that this is a manual process....ug..... this potentially means we might need to generate a build much less frequently.

so - could we add an extra param to the config for buildemailto and then at the bottom of the build script after generating the package could we do an md5 of the file, and send an e-mail containing the md5, filesieze and url of the file to the addressess specified in the new config param?

here's some code that I pinched from silverstripe to generate the md5/filesize etc if it might help....

md5=`md5sum $file | gawk " { print \\\$1 } "`
filesize=`ls -l $file | gawk " { print \\\$5 }"`

echo "A New Moodle WPI build has been generated: $file
-----------------------
Installer URL: http://download.moodle.org/download.php/direct/windows_wpi//$file
File Size: $filesize
MD5 Hash: $md5"

bit more hoop jumping required sorry! - looks like each build requires a different URL to give them time to update the link at their end. they're also asking for a changelog. Eloy do we have a nice script that generates a changelog from CVS from the last build? - we have some nice ways to do this in our git packaging processes, but I haven't done this based on CVS before.

here's the text of an e-mail I got from MS

Right now, it takes a couple of days for each new release to make it into the production feed. We're working on some systems to streamline this, but right now, we're being very cautious and making sure that every new release still works as expected. I think in the case of Moodle weekly builds, we might be better off sticking to every two weeks until we have this happening faster. If you could send us an e-mail with each new build, with the following info, it would help speed things up on our end:

1) New URL for the build
2) New MD5
3) Changelog from the last build
4) A note that identifies whether or not a new build is being released for security reasons. We fast track security fixes as much as we can.

Well,

I think we can:

• Change weekly build to monthly (to month's first Wednesday)
• Use the format: MoodleWindowsWpi-19-YYYMMDD.zip , storing last 10 builds or so.
• Provide one parallel: MoodleWindowsWpi-19-YYYMMDD.txt with md5 & filesize, email it to... you?
• About the changelog, the package includes it within the "moodle" dir. One standard changelog containing 1 month commits. Is that enough or needs to be out from the package?
• About security reasons... we only can rely on you, checking if something security-related has been published in the last month. If so, you can add that info to the email and forward it to MS. How does that sound?

Comments? Yes / No ?

Ciao

sounds great Eloy! - I think changelog inside the package should be fine - but I'll check to make sure - relying on me to filter security related stuff is fine too! - we may even be able to e-mail the results of the build script directly to MS (cc'ing me to help monitor for issues)

thanks!

Sure, we can send the mail directly to MS. The only point is the security information that cannot be included automatically (that was the cause to suggest the two step mail-out, 1st to you and you forwarding to MS with security warning if necessary). Or can the security warning be send in different mail (later, manually by you?).

In any case, to start having it finished... I'll add you as destination for mail...

yeah - I'm pretty sure a 2nd e-mail regarding Security issues should be fine! - thanks Eloy!

Reopening to work on this later... grrr. I've lost it from my list.... ciao

Hi Eloy - the MS reps are really keen to get this done - they've been in regular contact asking if I've got anywhere with it and if there's anything they can do to help!

any chance you could do this last bit of work this week? (e-mailing details and using a date in the filename?)

I still need to fill in some docs and send them through for HQ to sign/send to MS - will do that this week too.

thanks!

Dan

pinging me about this to have it raised in my list. grrr.

Here it's an example of the output being sent by email (txt file generated on each build):

Moodle 1.9 Windows Web Platform Installer (v. 2009032600)

Package: MoodleWindowsWpi-latest-19-20090525.zip
Date: 2009-05-25 06:21:07.000000000 +0800
Size: 15676327
MD5: 373642896807f6017188b31b3e428e60
SHA1: e708f68acb08167a0ed25f6f678c86d32a9f16ec
URL: http://download.moodle.org/download.php/direct/windows_wpi/MoodleWindowsWpi-latest-19-20090525.zip

Dan, I'm adding you to those mailouts right now, so you are going to be spammed with them with my next tests... so be warned!

The first "official" build should happen next Wednesday and next months.

About the security bit... perhaps it could be enough to add one link to some search in the Tracker? Something like "Security bugs resolved in last month". It would enable quick searching for that info

Ciao

Added last bits to the script:

1) Enable execution on Wednesday, from 21th to 27th (aka, monthly).
2) Added link to proper Tracker filter (restricted to developers) to know what security issues where fixed lasst month
3) Added support to keep last 6 packages, deleting automatically older ones
4) Results being sent by mail to MD, Dan and me.

Note next build will be next Wednesday, and then next Wednesday, from 21th to 27th, and next, and next...

.. seems to be working ok. So resolving as fixed. Ciao