Closed georeith closed 8 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...
@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?
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.
I'm happy to accept pull requests for this workflow if you'd like to work on that.
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.
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.)
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.
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?
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
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?
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
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! ;)
I've found a better way, I believe. I've separated the automatic build into prebuilt/dist
and prebuilt/module
branches:
prebuilt/dist
will be overriden with the latest zip file on each commitprebuilt/module
will be allowed to have a historySo 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!
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.