AppVeyor: fully automated build of 32- and 64-bit Windows binaries #1135

saper · 2015-09-09T12:14:00Z

For pull requests and pushes to master just build 32-bit binaries
and do not store artifacts.

Whenever a tag is pushed to the "release" branch - produce
full set of 32-bit and 64-bit binaries, create a GitHub
release (if does not exist already) and attach the binaries
to the release.

Issues open:

http://bit.ly/twoBuilds

AppVeyor starts two builds in response to the "new commit"
and "new tag" events.

http://bit.ly/bad_build_success

Parse error in the appveyor.yml causes the system to
silently ignore the commit.

http://bit.ly/appvLessDup

Is there a way to remove duplicate stanzas from
both configurations?

saper · 2015-09-09T12:19:45Z

I'd love to have your feedback @am11 @xzyfer. Right now it looks pretty cool to me! See the demo release https://github.com/saper/node-sass/releases/tag/v3.3.auto - one binary didn't make it due to timeout.

xzyfer · 2015-09-09T12:26:12Z

@saper NEAT!

Is there a way to remove duplicate stanzas from both configurations?

You could try YAML style inheritance eg.

development: &defaults
  adapter: mysql
  encoding: utf8
  database: acme_development
  username: root

test:
  <<: *defaults
  database: acme_test

cucumber:
  <<: *defaults
  database: acme_cucumber

am11 · 2015-09-09T12:49:43Z

This is brilliant! 👍
Probably we will not encounter timeout issues on our Sass org pro account, but probably a good idea to have some suitable action (like rebuild the commit) triggered by on_success and on_failure callbacks etc. Currently, AppVeyor does not support rebuilding a single job: appveyor/ci#244.

@xzyfer, I didn't knew about the YAML inheritance! Thanks for enlightening us. 😄

saper · 2015-09-09T12:56:45Z

https://ci.appveyor.com/tools/validate-yaml says: Invalid setting or section: << (Line: 13, Column: 4)

I think I have enough AppVeyor torture for today :)

xzyfer · 2015-09-09T12:59:55Z

IIRC merging is a common, but non-standard extension. I guess AppVeyors YAML parser doesn't support it :(

saper · 2015-09-09T13:05:29Z

I have disabled artifact storage for the casual testing configuration (normal builds). Do we need them? Are there any limits on how much we can store?

am11 · 2015-09-09T13:29:54Z

AFAICT, there is no limit on storage for Free or Pro accounts on AppVeyor cloud. At least I couldn't find it documented anywhere. Over at LibSass.net, I packaged the entire project folder (with sources) in artifacts and it has not complained so far: https://github.com/darrenkopp/libsass-net/blob/5c0ccec56/appveyor.yml#L20 (which is probably not a good idea to store ~60MBs x 4 jobs per commit and will probably violate the general "fair usage" clause of any cloud storage at some point)

saper · 2015-09-09T13:38:00Z

So the current setup (build for the release only) seems to be okay.

We still need to push the artifacts using your PowerShell snippet since otherwise AppVeyor refuses to deploy the files. (You cannot deploy out of the build files).

Maybe they delete artifacts once the build logs are removed, but I doubt it (extra effort + general cloudy "no delete" policy).

xzyfer · 2015-09-10T00:57:59Z

Could we plug this into node-pre-gyp? I like automating this but I'd rather not have a bespoke solution.

saper · 2015-09-10T06:39:25Z

... er which one you do not like? Not sure what I was talking about:)

saper · 2015-09-10T08:28:14Z

Here is a completed build:

https://github.com/saper/node-sass/releases/tag/v3.3.build

I am a bit unhappy about http://bit.ly/twoBuilds since it's really tricky to get the build running on the release branch and the tag at the same time. git push -f mostly doesn't work for me, I had to push a brand new commit and delete the other build.

For pull requests and pushes to master just build 32-bit binaries and do not store artifacts. Whenever a tag is pushed to the "release" branch - produce full set of 32-bit and 64-bit binaries, create a GitHub release (if does not exist already) and attach the binaries to the release. Issue open: http://bit.ly/twoBuilds AppVeyor starts two builds in response to the "new commit" and "new tag" events.

xzyfer · 2015-09-14T13:22:59Z

appveyor.yml

+    matrix:
+      - nodejs_version: 0.10
+      - nodejs_version: 0.12
+      - nodejs_version: 1


We need to add iojs@v1.0.x

https://github.com/sass/node-sass/blob/master/.travis.yml#L15

xzyfer · 2015-09-14T13:27:33Z

I've been thinking about this and I don't like AppVeyor creating the GH releases for us. I'd personally rather keep this as a manual step for the interim, until we move to node-pre-gyp.

I also personally really dislike having release notes a commit message. Release notes tend to be

heavily edited
collaborative

saper · 2015-09-14T14:11:57Z

On Mon, 14 Sep 2015, Michael Mifsud wrote:

I've been thinking about this and I don't like AppVeyor creating the
GH releases for us. I'd personally rather keep this as a manual step
for the interim, until we move to node-pre-gyp.

There is no magic that node-pre-gyp provides. It cannot create GH release
as well (see #1137 (comment))

I also personally really dislike having release notes a commit message. Release notes tend to be

heavily edited

collaborative

You can always edit it on GitHub. I only needed something
to put there in case AppVeyor is the first one to create
the release. It can be a static boilerplate, I just picked
up the commit contents since it sounded like a cool idea to me,
but those are by no means "final" release notes.

I haven't tested this, but if you create the release
manually before your trigger the CI build - your
description there will stay (AppVeyor does not touch
GH releases if it finds them, it only creates one
if it does not exist - with the script-supplied description).

xzyfer · 2015-09-14T14:41:13Z

Thinking about the double build problem. I think the problem is that you're
pushing the tag. Have you tried creating a released via the GH UI? Releases
create tags. That sounds like it'll work better with the AppVeyor approach.

I almost exclusively rely on GH releases for creating tags.
On 15 Sep 2015 00:12, "Marcin Cieślak" notifications@github.com wrote:

On Mon, 14 Sep 2015, Michael Mifsud wrote:

I've been thinking about this and I don't like AppVeyor creating the
GH releases for us. I'd personally rather keep this as a manual step
for the interim, until we move to node-pre-gyp.

There is no magic that node-pre-gyp provides. It cannot create GH release
as well (see
#1137 (comment))

I also personally really dislike having release notes a commit message.
Release notes tend to be

heavily edited

collaborative

You can always edit it on GitHub. I only needed something
to put there in case AppVeyor is the first one to create
the release. It can be a static boilerplate, I just picked
up the commit contents since it sounded like a cool idea to me,
but those are by no means "final" release notes.

I haven't tested this, but if you create the release
manually before your trigger the CI build - your
description there will stay (AppVeyor does not touch
GH releases if it finds them, it only creates one
if it does not exist - with the script-supplied description).

—
Reply to this email directly or view it on GitHub
#1135 (comment).

xzyfer · 2015-09-14T14:49:48Z

For reference by GH release workflow is

npm version patch --no-git
git add package.json
git commit -m "v3.3.3"
git push

When CI is green

create the GH release
- which creates the tag
git pull --rebase
npm publish

Fix call function incorrectly expanding map arguments

saper self-assigned this Sep 9, 2015

saper added OS - Windows npm build Dev - WIP labels Sep 9, 2015

saper mentioned this pull request Sep 9, 2015

Automate building of binaries #56

Closed

saper mentioned this pull request Sep 9, 2015

Allow common configuration in branches-specific appveyor.yml appveyor/ci#325

Closed

saper force-pushed the appveyor_auto branch from 2b7307b to 8d0a6da Compare September 10, 2015 09:56

saper force-pushed the appveyor_auto branch from 8d0a6da to 73b52c9 Compare September 10, 2015 09:59

saper mentioned this pull request Sep 11, 2015

Run OSX builds in Travis CI #1137

Merged

xzyfer reviewed Sep 14, 2015
View reviewed changes

Add io.js 1.0.x for binaries version 42

3c954ce

saper closed this in 30b2b14 Sep 18, 2015

xzyfer added this to the next.patch milestone Sep 18, 2015

xzyfer removed this from the next.patch milestone Oct 27, 2015

xzyfer modified the milestones: v3.4.0, next.patch Oct 27, 2015

jiongle1 pushed a commit to scantist-ossops-m2/node-sass that referenced this pull request Apr 7, 2024

Merge pull request sass#1135 from xzyfer/fix/issue-1133

a140623

Fix call function incorrectly expanding map arguments

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AppVeyor: fully automated build of 32- and 64-bit Windows binaries #1135

AppVeyor: fully automated build of 32- and 64-bit Windows binaries #1135

saper commented Sep 9, 2015

saper commented Sep 9, 2015

xzyfer commented Sep 9, 2015

am11 commented Sep 9, 2015

saper commented Sep 9, 2015

xzyfer commented Sep 9, 2015

saper commented Sep 9, 2015

am11 commented Sep 9, 2015

saper commented Sep 9, 2015

xzyfer commented Sep 10, 2015

saper commented Sep 10, 2015

saper commented Sep 10, 2015

xzyfer Sep 14, 2015

xzyfer commented Sep 14, 2015

saper commented Sep 14, 2015

xzyfer commented Sep 14, 2015

xzyfer commented Sep 14, 2015

AppVeyor: fully automated build of 32- and 64-bit Windows binaries #1135

AppVeyor: fully automated build of 32- and 64-bit Windows binaries #1135

Conversation

saper commented Sep 9, 2015

saper commented Sep 9, 2015

xzyfer commented Sep 9, 2015

am11 commented Sep 9, 2015

saper commented Sep 9, 2015

xzyfer commented Sep 9, 2015

saper commented Sep 9, 2015

am11 commented Sep 9, 2015

saper commented Sep 9, 2015

xzyfer commented Sep 10, 2015

saper commented Sep 10, 2015

saper commented Sep 10, 2015

xzyfer Sep 14, 2015

Choose a reason for hiding this comment

xzyfer commented Sep 14, 2015

saper commented Sep 14, 2015

xzyfer commented Sep 14, 2015

xzyfer commented Sep 14, 2015