royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: Testing npm deployment
Date Mon, 18 Dec 2017 18:26:54 GMT
Okay, this is one way to do it which I am not too opposed to.

So, at this point, I assume there is nothing else to do to as far as npm
goes?

How can I help?

I will leave my branch as is in case we decide to go that route at a later
point of time.

Thanks,
Om

On Dec 18, 2017 10:04 AM, "Alex Harui" <aharui@adobe.com.invalid> wrote:

> That is the question I've been asking for several posts now.  AIUI, when
> you publish a package in NPM, the package is copied to NPM's servers.
>
> This post [3] implies that we should not use "npm publish" on anything
> that isn't released.
>
> So my conclusion, and what I checked in, was two NPM packages (royale and
> royale-swf) that are the same as the binary convenience package generated
> by Ant, since I think the NPM package must be generated by a build of the
> source package.  To get a nightly, you use:
>
>   npm install <url to nightly>
>
> The royale and royale-swf packages have different URLs up on the CI server.
>
> To get the RC versions some day, you would run:
>
>   npm install http://dist.a.o/dev/royale/rc1/<binary-convenience-package>
>
> It is my understanding that when the vote passes, the release manager
> script will move the bits from dist.a.o/dev to dist.a.o/release and can
> just run "npm publish" for both royale and royale-swf and it will copy the
> convenience packages to NPM's servers and then when folks do:
>
>   npm install royale (or royale-swf)
>
> It will download that package and no mirrors are involved at all (which
> reduces a point of failure for us).
>
> Again, I am an NPM newbie, so maybe I am making a bad assumption, but this
> is my understanding based on the links I've presented.
>
> Thanks,
> -Alex
>
> [3]
> https://stackoverflow.com/questions/21355508/publish-
> development-version-of
> -npm-package
>
> On 12/18/17, 9:19 AM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >We need multiple versions of package json: release jsonly, nightly jsonly,
> >rc jsonly, release jsandswf, nightly jsandswf, rc jsandswf.
> >
> >Nightly and rc builds need to be loaded from static urls, wheras releases
> >need to be loaded from a mirror.   Where will mirror url resolution take
> >place?
> >
> >How are you planning to support this in your approach?
> >
> >Thanks,
> >Om
> >
> >
> >On Dec 18, 2017 8:45 AM, "Alex Harui" <aharui@adobe.com.invalid> wrote:
> >
> >Hi Om,
> >
> >My logic is that package.json goes into a binary artifact for NPM, so at
> >some point, we are supposed to vote on package.json being correct.  If you
> >modify package.json after the vote, or don't put in in a source artifact,
> >we are technically releasing an unapproved file.
> >
> >If we find something wrong with any of our binary artifacts, we probably
> >have to cut another release if it requires a change to any file in our
> >source package to fix it.  Why is NPM a bigger risk for problems than
> >Maven or Ant?
> >
> >Testing changes to NPM packaging shouldn't require waiting for the CI
> >server.  You run the build locally, and run "npm install <path to output
> >folder or gzip>"  See [2]
> >
> >Scripting string replacement to change the package URL from the CI server
> >to the mirror system is potentially tricky.  We did that for Flex and the
> >Installer and sometimes I had to manually correct it, and I was glad to
> >see that we didn't need it in Royale if we had NPM distribute the binary
> >package.
> >
> >It looks to me that NPM has a "convention" to use URLs for nightly builds
> >and that we should use it, and not create our own, or have to rely on the
> >mirror system either.  That's what I had checked in.  The thing I liked
> >about it was that when you installed the js-only package, no further
> >scripts needed to be run.  The package is self contained and didn't need
> >to go out to another server.
> >
> >What I checked in I thought was more conforming to NPM's conventions and
> >reduced a point of failure by not relying on the mirror system.  But I'm
> >an NPM newbie, so I may be missing something.
> >
> >-Alex
> >
> >[2]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fdocs.npmj
> >s.com%2Fhow-npm-works%2Fpackages&data=02%7C01%7Caharui%40adobe.com
> %7C4e762
> >d4c0a6340f2307408d5463b8432%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6
> >36492143796733169&sdata=MF%2FOg7za7B0K0g7aMIoXMn%
> 2BeS41nz4f3Do%2B17u7dzdU%
> >3D&reserved=0
> >
> >On 12/18/17, 1:14 AM, "omuppi1@gmail.com on behalf of OmPrakash
> Muppirala"
> ><omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >
> >>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui <aharui@adobe.com.invalid>
> >>wrote:
> >>
> >>> Hi Om,
> >>>
> >>> I'm not sure what your definition of "direct dependency" is, but we
> >>> already have Maven stuff in the source package so we can directly
> >>>publish
> >>> Maven artifacts to Maven central.  What is wrong with having NPM stuff
> >>>in
> >>> the source package as well?
> >>>
> >>
> >>If something went wrong with an npm release, we will need a new release
> >>of
> >>the Source and Binary artifacts.  That takes a much longer time.  We
> >>should
> >>avoid a scenario like the dependency between the SDK and the Installer,
> >>which sometimes requires a new release of SDK for pushing out changes to
> >>the Installer.
> >>
> >>
> >>>
> >>> The plan is currently to run the Maven release steps, which will create
> >>>a
> >>> set of 3 source artifacts (one per-repo), then run an Ant script that
> >>> turns those 3 source artifacts into one source artifact that we vote
> >>>on,
> >>> along with two IDE-friendly binary artifacts (with and without SWF
> >>> support), and dozens of Maven SWCs and JARs, and, as the scripts
> >>>are/were
> >>> currently setup, the two IDE-friendly binary artifacts should have been
> >>> valid NPM artifacts.  Once the vote is approved, the Maven artifacts go
> >>>to
> >>> Maven Central, the IDE-friendly artifacts go to dist.a.o, and
> >>> theoretically, those same artifacts get published to NPM (unmodified).
> >>> And that can all be scripted.
> >>>
> >>
> >>I don't get the part where it has to be unmodified.  Right now, if I need
> >>to change the package.json, I need to push a fix, wait for a nightly
> >>build
> >>before I can test it out.  If we do it my way, composing the npm package
> >>is
> >>a completely separate process without having to wait for sdk changes to
> >>be
> >>propagated.
> >>
> >>
> >>>
> >>> I don't know NPM that well, so maybe something does have to change in
> >>> package.json before actual publication, but if not, I don't understand
> >>>why
> >>> the RM should need to do more than just run "npm publish" once or
> >>>twice.
> >>> IMO, it is sort of cheating to modify package.json or any other files
> >>> after a vote on those files to create the NPM artifacts.
> >>>
> >>
> >>Only if package.json is part of the source artifact.  I don't see the
> >>need
> >>to have package.json file and other npm related scripts in the source or
> >>binary artifacts.
> >>
> >>
> >>>
> >>> Also, I think I proved that the Ant script on the CI server can create
> >>> valid NPM artifacts for nightly builds.  I would think we would want
> >>>that
> >>> instead of needing some manual step to make nightly builds available
> >>>for
> >>> NPM users.
> >>>
> >>
> >>Anything that is manual can be scripted.  My goal is to make an "publish
> >>to
> >>npm" script available that can be tacked on to the current release
> >>process.
> >>
> >>
> >>>
> >>> It sounds like you are basically reverting all of the NPM work I just
> >>>did.
> >>> :-(
> >>
> >>
> >>I'm sorry about that.  I was not paying attention to your commits in this
> >>area. What exactly am I reverting?  The stuff I am doing right now is in
> >>addition to what you have already done.
> >>
> >>
> >>> How were you planning to provide nightly builds and not modify
> >>> approved sources to publish NPM artifacts?
> >>
> >>
> >>I sent a couple of emails about this a while ago.
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Flists.ap
> >>a
> >>che.org%2Fthread.html%2F86253b3e04f138d7c4ed6f1769c2
> 654da6d47b8ca10c88b7d
> >>c
> >>582d91%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%
> 40adobe.co
> >>m
> >>%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C
> >>0
> >>%7C0%7C636491853411797328&sdata=lDClXqNwbfMlYzDMjdu%
> 2BonaFDU45N6NppoVHfsY
> >>r
> >>q70%3D&reserved=0
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Flists.ap
> >>a
> >>che.org%2Fthread.html%2F66e1ee3ce5ce0294b18913c83c79
> 4a8819893ba9bb73e77f5
> >>5
> >>b5cfce%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%
> 40adobe.co
> >>m
> >>%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C
> >>0
> >>%7C0%7C636491853411797328&sdata=iCM20R4mlH52eIWURoWvYzNregXW7P
> eZJCM7KRhbs
> >>U
> >>0%3D&reserved=0
> >>
> >>I am yet to get to this part.  But we need to sort off agree on a path
> >>before I can proceed.
> >>
> >>
> >>>   I'm shutting down for tonight
> >>> so I'll pick this up in the morning.
> >>>
> >>> Thanks,
> >>> -Alex
> >>>
> >>> On 12/17/17, 11:42 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>> Muppirala" <omuppi1@gmail.com on behalf of bigosmallm@gmail.com>
> wrote:
> >>>
> >>> >On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui
> >>><aharui@adobe.com.invalid>
> >>> >wrote:
> >>> >
> >>> >> Om,
> >>> >>
> >>> >> One thing I'm confused about:  When I read about NPM publishing
[1],
> >>>it
> >>> >> sounds like you can publish a folder of stuff (and/or a gzip of
that
> >>> >> folder) and thus the binaries shouldn't need to be downloaded off
of
> >>>one
> >>> >> of our servers.  But it looks like the old FlexJS script and now
> >>>these
> >>> >> scripts are trying to download the binaries off of one of our
> >>>servers.
> >>> >>
> >>> >> Thoughts?
> >>> >> -Alex
> >>> >>
> >>> >> [1]
> >>> >>https://na01.safelinks.protection.outlook.com/?url=
> >>> https%3A%2F%2Fdocs.npm
> >>> >>js.com%2Fgetting-started%2Fpublishing-npm-packages&
> >>> data=02%7C01%7Caharui%
> >>> >>40adobe.com%7Cc45ced0b53984ddecf5208d545eb06c2%
> >>> 7Cfa7b1b5a7b34438794aed2c1
> >>> >>78decee1%7C0%7C0%7C636491798101208728&sdata=
> >>> T3Ym%2BwQPX15EKsN7rWAZhtttSDv
> >>> >>KxYARMMi3KiZqTd4%3D&reserved=0
> >>> >
> >>> >
> >>> >I am a bit unclear on your how you are thinking of publishing to npm.
> >>>You
> >>> >want to simply publish the binary release artifact to npm?
> >>> >
> >>> >When will the properties in package.json be updated?  When creating
> >>>the
> >>> >binary artifact or when we are publishing to npm?
> >>> >
> >>> >In my mind, the release artifact should not contain any npm related
> >>>stuff.
> >>> >As a release manager, I would like to download the release artifact,
> >>>add
> >>> >in
> >>> >all the npm related stuff and then publish to npm.  I am adding this
> >>>logic
> >>> >into a script so that the release manager can simply run it as part
of
> >>>the
> >>> >release process.
> >>> >
> >>> >This way, we don't have a direct dependency between the royale
> >>>codebase
> >>> >and
> >>> >the npm related stuff.
> >>> >
> >>> >Thanks,
> >>> >Om
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >>
> >>> >>
> >>> >> On 12/17/17, 1:56 PM, "omuppi1@gmail.com on behalf of OmPrakash
> >>> >>Muppirala"
> >>> >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
> >>> >>
> >>> >> >I have pushed a few changes to my branch:
> >>> >> >https://na01.safelinks.protection.outlook.com/?url=
> >>> >> https%3A%2F%2Fgithub.co
> >>> >> >m%2Fapache%2Froyale-asjs%2Fcommits%2Ffeature%2Fnpm-
> >>> >> scripts&data=02%7C01%7C
> >>> >> >aharui%40adobe.com%7Cd583a0036a204c481bde08d54599
> >>> >> 0bde%7Cfa7b1b5a7b34438794
> >>> >> >aed2c178decee1%7C0%7C0%7C636491446017963669&sdata=
> >>> >> DhjL2mrknpft7aEadZpgXnaV
> >>> >> >g2w4AKcvSt8K1nQj9R4%3D&reserved=0
> >>> >> >Can someone give it a look over before I merge it into develop?
> >>> >> >
> >>> >> >Once it gets merged into develop, I can test out the build
from the
> >>> >> >lastSuccessfulBuild from the jenkins build.
> >>> >> >
> >>> >> >I've given the package a dummy name till we test it out so
that we
> >>> >>don't
> >>> >> >accidentally push a build out.
> >>> >> >
> >>> >> >Thanks,
> >>> >> >Om
> >>> >>
> >>> >>
> >>>
> >>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message