In my Release post-build event I run node.exe in order to minify and combine my javascript files with RequireJS. This creates new folders and minified files inside my website folders which I then reference in my HTML when debugging is disabled.
node.exe is contained within my source control, and building this on my local machine works fine.
When this is built on AppHarbor, I am getting the following error straight after running
"node.exe <<PATH TO r.js>> -o <<PATH TO app.build.js>>"
:
fs.js:520
return binding.lstat(pathModule._makeLong(path));
^
EXEC : error : EPERM, operation not permitted 'D:\temp'
Is this because I don't have permission to create folders/files on AppHarbor? How would I be able to get around this and build the minified files?
I don't want to have the minified files pre-built into source control.
From AppHarbor FAQ:
http://support.appharbor.com/kb/getting-started/frequently-asked-questions
My application cannot write files
By default, applications deployed on AppHarbor can only write to the App_Data folder.
You can enable write access to the entire application directory application settings.
Note that changes (both to App_Data and the rest of the application directory) are not persisted between deploys and you should only use it for caching and other temporary uses.
Hope this helps ;)
The best way to resolve this is probably reproduce the AppHarbor build locally and ensure that everything goes where it's supposed to go. This is what you want to run: msbuild solution.sln /p:Configuration=Release /property:OutDir=C:\temp. There's more in the FAQ: http://support.appharbor.com/kb/getting-started/frequently-asked-questions
Related
I am planning on moving from "EmberJS" to the Ember-cli, though I have a small problem. Is it possible only to run file watcher instead of serving/using ember serve that will run local server? As I am running my PHP backend on the Google App Script I have already a local python HTTP server running in localhost:8080 I do not need another one to run in localhost:4200
If I don't run ember serve my local changes in development environment wont get updated. Is there a better way of doing this? Is it possible to use assets in the app folder when running in development environment? and use dist folder for staging/live environments?
As mentioned in the guide, you can use the build command with the --watch flag.
ember build --watch
That will keep rebuilding your changes but not actually run the server.
As for your second question:
Is it possible to use assets in the app folder when running in development environment? and use dist folder for staging/live environments?
I don't believe so. You can change the output-path property in your .ember-cli config file, but you can't have one that's specific to a certain environment. You could always write a quick script to move the files though. :)
I'm setting Django on production server and have this strange error(on picture below)
As you can see pythonpath seems to be ok(first row is my project folder), I definitely have module urls.py inside my project/project folder, I have init file there and my ROOT_URLCONF = 'project.urls'(I also tried without project name, but it didn't help either).
So, that is strange why it can't find it :(
I have to say that I tried to create a new project on server and then it seems to be ok, but with this project that is copied from local server it is behaving like this.
Printscreen of error:
The only problem I can think of is the process of package creation. What process have you followed to deploy your Django application?
If you have compiled the Django application on your local machine or CI server and then deployed the compiled package then you will run into Import module issues because pyc files will contain hard coded paths of your local machine or CI servers. To fix it before compiling the python files you should create the same hierarchy on your local/CI server and then compile and deploy.
Hope this helps.
[Edit]
I agree hardcoded paths in pyc files is PITA and we have been doing this in our production environment once we discovered it.
However I do not agree with you to re generate pyc files on the server because as your application will grow and you move towards a large application it will become very slow.
You don't have to keep your development environment directory to follow production directory structure. Instead you can have any directory path on development machine and create a separate bash script which will create a package for you by creating a directory structure that you follow on production. Bash script will have the logic of
Creating a directory structure similar to production
Checking out the code from source control
Compile the code using python -m compileall .
Create a tarball
You can untar this tarball on production server and your application should run fine.
For more information about package creation in python and best practices, check out this video
It doesn't look like your project is in your path, actually. The traceback is only showing Django packages.
I want to have some custom steps run during them ember cli build, is there a supported way to do that? Specifically, I want to parse comments in css files and build write files to the public directory based on those comments.
You should create an ember-cli addon to create extra build steps. There is some good documentation around on Google, but here is a blog post I used to create addons. This guide is more tailored toward creating ember components but there are other ember-cli hooks you could use to run code during the build process.
Perhaps you could use the included hook to run some code to read your css files and then import your files into the public directory. Other hooks that you could use are documented here
Alternatively, if there is a broccoli plugin that does what you want, you simply need to add it to your package.json and run npm install. Now the plugin has been added to the build system.
I have been trying to get Gradle working on our Continuous Integration server, which has no access to internet (external) URLs.
Currently, we get our maven-style dependencies from an internal proxy server. So I uploaded the gradle wrapper onto that server too, such that when the CI server starts up it can download the wrapper from the internal maven proxy server.
Problem solved, I thought; the build will carry on and pull down the project dependencies from the internal proxy server as well (it's set up in the build script) and should be OK now.
But in between getting the wrapper Zip file and starting the build, it's doing the following:
Downloading http://maven.internal.mycompany.com:8081/nexus/content/repositories/thirdparty/org/gradle/gradle/1.0-milestone-3/gradle-1.0-milestone-3-bin.zip ................
Unzipping /home/user/.gradle/wrapper/dists/gradle-1.0-milestone-3-bin.zip to /home/user/.gradle/wrapper/dists
Set executable permissions for: /home/user/.gradle/wrapper/dists/gradle-1.0-milestone-3/bin/gradle
Download http://repo1.maven.org/maven2/org/codehaus/groovy/groovy/1.7.3/groovy-1.7.3.pom
Download http://repo1.maven.org/maven2/antlr/antlr/2.7.7/antlr-2.7.7.pom
etc...
*** then the actual build starts ***
Download http://maven.internal.mycompany.com:8081/nexus/content/groups/public/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
E.g. it's trying to pull down extra dependencies for the gradle executable from repo1.maven.org which fails on the continous integration server, as it has no access to this server.
In my build.gradle file I have:
repositories {
mavenRepo urls: "http://maven.internal.mycompany.com:8081/nexus/content/groups/public"
}
and in my ./gradle/wrapper/gradle-wrapper.properties file I have :
distributionUrl=http\://maven.internal.mycompany.com:8081/nexus/content/repositories/thirdparty/org/gradle/gradle/1.0-milestone-3/gradle-1.0-milestone-3-bin.zip
So is there another place I can specify which server the wrapper should use to get it's additional dependencies ? Or is this hard-coded into the wrapper itself ? Or I might be missing a trick here, as Google doesn't seem to show up anyone else having this issue at all !
Ben
Picked up a hint from another forum that led me to the answer - a plugin for cobertura that I was pulling down had it's own gradle build file that included the default maven repositories.
I've removed that now, and the calls to external maven have ceased.
I have a WCF DataService build in VS 2010, targetting .Net 4.0. This all works fine. I've created a deployment package and have the application deployed to a web server using MSDeploy and a zip file. When I set up an automated build on a TFS Build Agent the contents of the deployment package changed. I no longer get the strong named assemblies in my deployment package. These excluded assemblies are projects within the solution and are built on the Build Server.
I don't see a lot of configuration options for the deployment package, but I would like to know why the build server creates a different package than my workstation, using the same settings.
I am using "Only files needed to run this application", I have ticked "Exclude generated debug symbols" and "Exclude files from App_Data folder". I _do_not_ include database packages. I do create a zip file (which is missing the strong named assemblies)
Thanks for any information you may have explaining why this occurs. Then maybe I can solve the problem.
Beezler
On the build server I've ungaced the assemblies I was concerned about and that got my deployment package to the state I want it. So it appears the deployment package does not include the GACed assemblies, which is a good thing. I would still like to know how to override this behavior on certain referenced assemblies.
Thanks,
If you want to include a DLL files for a GAC assembly do the following:
In your project, expand the "References" folder
right-click on the reference you want to include the DLL and click "properties" to bring up the properties pane
set "Copy Local" to "True"
That's it! When publishing your project, it will include the DLL in the bin folder for that reference!