deploy.js issues

edited September 2013 in Enyo 2
I think that the latest deploy.js may have a couple issues but thought I'd check if I'm doing something wrong here.

1) First to specify an alternate main package.js to use in the deploy, after reading through the deploy.js comments & code a bit it looks like you should just need to specify an alternate "source" location in your deploy.json, ie like so:
	"source": "path to alternate package.js"
However that will just break the build with numerous errors. I also tried leaving source alone as "." & calling deploy with the old -p option with the path to my other package.js, which appeared to work but looks like deploy.js now just overwrites that option with the source option from deploy.json so it doesn't actually use the alternate package.js. I tried a bunch of configurations here but couldn't get anything to work with an alternate package.js'

2) Also I noticed that the deploy.json asset copying doesn't handle copying directories that are deeper than just the assets directory as I think would be expected. For example say you have something like this:
assets
  images
    full
    thumbs
where full & thumbs are both directories of images rather than files.

Then in your deploy.json you specify:
	"assets": ["assets/images/full"],
You end up getting everything in the assets/images directory (ie full & thumbs directories).

Do these both sound like bugs or anything obvious I'm doing wrong/assuming here?

Comments

  • These both seem like bugs... I've asked FiX to check out this thread and comment.
  • 1) It looks like I may have messed up the interaction logic between -s & -p. I need to clean that: there should be no interaction at all

    2) Indeed, there is a limitation here. Would you want for example "resources/assets/images" to be copied as "resources/assets/images" without coping the whole "resources/*"? Something else?

    I have just filled https://enyojs.atlassian.net/browse/ENYO-3012. Feel free to watch it.
  • Ok great to know, thank you guys.

    On #2 what I was expecting to happen was as you put it - "resources/assets/images" to be copied as "resources/assets/images" without coping the whole "resources/*". Just hoping to be able to single out directories & files.
  • @slojs I did a couple of tests with various applications folder layout using a new version I just uploaded at https://github.com/enyojs/enyo/tree/ENYO-3012. But I am not sure that it will work for you. Would it be possible to checkout this Enyo branch in your application & tell me wether it gives you a way out of your issues? If yes, I will iterate to make the change (and its impacts) more widely available.

    Thanks in advance.
  • Wow thank you! I tested it out & it almost works. It's building with the proper package but I found that the image url's in my app.css get bad paths. Specifically they point several levels up the hierarchy. I've uploaded a full example here - https://dl.dropboxusercontent.com/u/98692823/test.tar.gz - it has a deployed version already created OR you can run deploy.sh to recreate.

    Please let me know if I can provide more information or further testing & thank you!
  • FYI - I tried responding to the bug too, but JIRA doesn't let me finish the account creation process!
  • That sounds weird... What does JIRA say? I'd love to hear more about our users directly on JIRA, so it is important that JIRA does not hate them ;-)

    Thanks for the tarball. I will have a look at it.
  • Issue fixed. More details at https://enyojs.atlassian.net/browse/ENYO-3012. Thanks again for the test tar ball @slojs !
  • It is fixed! & I can't believe I'm getting up to find all my problems solved - it's like Christmas :-) Thank you so much, this really makes the deploy process flexible and easy.

    JIRA isn't letting me complete registration. The captcha box seems to be out of order - it is just blank in some browsers & shows a broken image in others. If I could log in I'd file a bug :P
  • The JIRA server is giving a 500 error for the CAPTCHA image. I'll raise an issue with their support.
  • edited January 2014
    I'm running into another issue with deploy.js. Not sure when this started, sometime in the last month, I updated everything, redeployed and saw this. I'm using a Notification library from Macfja. And started seeing issues, tracked it down and images are missing. Figured out that the deploy process isn't parsing URLs properly. MacFJA uses an Enyo gradient in CSS like this:
    
    background: rgba(0,32,192,0.75) url(http://enyojs.com/lib/onyx/images/gradient.png);
    
    And it turns it into this (note the double set of single quotes at the end of the URL):
    
    background: rgba(0,32,192,0.75) url('http://enyojs.com/lib/onyx/images/gradient.png'');
    
    Manually editing the app.css file and removing the extra ' at the end fixes my issue. I tried editing the CSS file and rebuilding with each of these variations:
    
    background: rgba(0,32,192,0.75) url(http://enyojs.com/lib/onyx/images/gradient.png);
    background: rgba(0,32,192,0.75) url('http://enyojs.com/lib/onyx/images/gradient.png');
    background: rgba(0,32,192,0.75) url("http://enyojs.com/lib/onyx/images/gradient.png");
    
    But all these variations give the same result.
    
    background: rgba(0,32,192,0.75) url('http://enyojs.com/lib/onyx/images/gradient.png'');
    
  • Please file a bug at jira.enyojs.com on this... I'm guessing that the regex in the deploy script isn't handling full URLs very well.

    In the meantime, you can try changing the notification CSS to use url("$lib/onyx/images/gradient.png") to have it use the copy of the image you deploy with your app instead of relying on an external resource.
  • Tried, $lib, made it worse. Looks like it prepended the current, relative library path onto the existing path without transforming the $lib variable.
     url('../lib/macfja/notification/NotificationTheme/css/$lib/onyx/images/gradient.png');
    I will fork MacFJA's project this week and add the images to the module.
Sign In or Register to comment.