paperjs / paper.js

The Swiss Army Knife of Vector Graphics Scripting – Scriptographer ported to JavaScript and the browser, using HTML5 Canvas. Created by @lehni & @puckey
http://paperjs.org
Other
14.5k stars 1.23k forks source link

Update dist between commits #629

Closed georeith closed 8 years ago

georeith commented 9 years ago

Is there a reason we don't updated the dist folder except for releases?

It would be useful for those using package management tools like bower that may need to point at a specific commit version before it is packaged into a release and be able to pass it on to a team mate so that they don't have to manually build paperjs each time.

The dist folder should still be correct for the release at the time, but those pulling a specific commit like want the built version of that.

Update: Actually you can't build from a commit through bower at all as it ignores the build directory.

lehni commented 9 years ago

The reason is that when developing, we're using the load.sh script to produce a shin paper-full.js file that loads each separate script file from the src folder, rather than a built version of the library (see README). This facilitates rapid development and debugging cycles, as we can step through the actual script files in the src folder, and pick up changes in them after a reload without having to build the library on each change. Including a built library in each commit would mean we'd have to manually run the build script before each commit... Not really ideal...

georeith commented 9 years ago

@lehni I see.

Perhaps we could commit the nightly builds in that case, so that they can be pointed to for a more up to date version between official releases for people using package managers. I'm not sure what you use to perform the nightlies but I'm guessing this is some kind of automated CI tool?

dippi commented 9 years ago

would mean we'd have to manually run the build script before each commit...

Well, @lehni, you could automate the build with a git hook :) (See: hooks man page and this SO Question)

Or, how @georeith suggests, commit the nightly builds, but maybe on an orphan branch to keep the master clean.

lehni commented 9 years ago

I'm happy to accept pull requests for this workflow if you'd like to work on that.

dippi commented 9 years ago

Which solution: hook or nightly?

About hook:

About the nightly: it should be equally easy, I can help you to setup the branch and the automation if you share some deail on the CI tool.

dippi commented 9 years ago

This could be the hook:

#!/bin/sh
echo "Building paper.js"
./build/build.sh
echo "Minifying paper.js"
./build/minify.sh
echo "Adding dist/ to commit"
git add -u dist/

and it's enough to save it as .git/hooks/pre-commit with permissions to execute. (Note: the files added in this way wont appear in the commit message, but they will be committed. See the SO question linked in my first comment for details.)

dippi commented 9 years ago

And for the nightly, this script could do the setup:

#!/bin/sh
git checkout --orphan nightly
git reset
rm -rf !(.|..|.git) # NOTE: requires extended globbing
wget "http://paperjs.org/download/paperjs-nightly.zip"
unzip paperjs-nightly.zip
rm paperjs-nightly.zip
git add .
git commit -m "Nightly 2015-01-27"
git push origin nightly:nightly
git checkout master

It creates a new orphan branch called "nightly", deletes everithing from it, download and extract the nightly from your server, adds all the files, commit as "Nightly 2015-01-27" and push to origin. (See: extended globbing, but you can do without)

And guessing that your CI tool runs the script ./build/dist.sh, you should have the zip generated by ./build/zip.sh in the dist/ folder, you could add this script to the tool chain:

#!/bin/sh
cp ./dist/paperjs.zip /tmp/
git checkout nightly
rm -rf !(.|..|.git) # NOTE: requires extended globbing
unzip /tmp/paperjs.zip
rm /tmp/paperjs.zip
git add -A .
git commit -m "Nightly $(date +%F)"
git push origin nightly
git checkout master

There are possible refinements (e.g.: add the sha of the master commit in the nightly comment, add some logging and handle possible exceptions), but it should work!

@lehni, let me know if you have doubts and if I can be of some help.

lehni commented 9 years ago

I'm really reluctant to do local hooks, since a couple of people are involved... Also, there is a change to how we're working with branches: From now on, all development will take place in the https://github.com/paperjs/paper.js/tree/develop branch. There, the load.js script is used to load the library from the separate source files (see 113f54f0af0ae8e4f162d86bd02ba6be2b05ba79), facilitating quick development and precise debugging. If I want to test the built, scoped library instead, I run the build/build.sh script to create it, and build/load.sh after to switch back to the load.js version (or I simply discard the changes to the dist folder in git). Before a new version gets released, the develop branch is merged into master, where the built version is then committed and tagged as the release, like before.

What we could do is a script that merges develop into develop-built or something the like, runs the build script and commits the built library, once a day. I already have a daily script running that publishes paperjs.org to github. This script could take care of that extra step as well. This could then be used to require specific commit versions from package managers. @georeith would this do the job?

lehni commented 8 years ago

I have switched to Gulp now for the full building process. Does this reduce the need for these regular builds? We also will have the nightly builds working shortly again (at the moment it's from yesterday): paperjs-nightly.zip

lehni commented 8 years ago

I've finally implemented this, through Travis CI. You get a full build on each commit here, including a ZIP file too:

https://github.com/paperjs/paper.js/tree/build

This should also work for inclusion through NPM.

What I currently don't do is keep the versions around. I override the orphaned branch with a new build each time. What do you think, would it be better if it was allowed to grow a history?

lehni commented 8 years ago

If you're curious about the implementation. The script files are here:

https://github.com/paperjs/paper.js/tree/develop/travis

And the travis file here:

https://github.com/paperjs/paper.js/blob/develop/.travis.yml

dippi commented 8 years ago

Great, well done!

About growing a history, I don't think it shoud be necessary, because using the nightly implies this kind of uncertainty and anyway if you want to get a previous version you can build it from source. At the same time I don't see a particular reason not to do that.

So I'm not able to give you a strong advice on what to choose, I'll just say: go for whatever suits you and wait for somebody to complain! ;)

lehni commented 8 years ago

I've found a better way, I believe. I've separated the automatic build into prebuilt/dist and prebuilt/module branches:

lehni commented 8 years ago

So after a ton of struggles with Travis CI, the change above is finally working. Here an example of an incremental commit to prebuilt/module. I think this will be a really useful way to quickly see what changes between versions:

https://github.com/paperjs/paper.js/commit/b7331bad985e9d95ba3ae3ff2040143e23de7c48

And here the source of the struggles:

https://github.com/paperjs/paper.js/blob/develop/travis/setup-git.sh#L22

We can finally close this!