I am trying to deploying my website on Netlify from my GitHub.
However I am stuck to the following error:
11:37:19 AM: failed during stage 'deploying site': Invalid filename 'node_modules/es5-ext/date/#/format.js'. Deployed filenames cannot contain # or ? characters
I tried to delete and upgrade the module es5-ext but the error persists.
I don't know if i'm too late to this but I just ran into this issues
here's what I did which fixed my issues
base directory : yourApps
build command : CI= npm run build
publish directory : yourApps/build
I used craco in my react apps because I needed it to work with Tailwind css , I don't know if this will work for you , but that solution worked for me
My first answer is a question: Why are you deploying your node_modules folder? That is generally not needed on static websites: they're used to build the site, but then not needed at runtime, since, well, "runtime" is just "send this file" not "run this code" on the Netlify CDN server. Perhaps you've set your "publish directory" wrong in the site's build & deploy settings and are deploying your source code too, rather than just the finished build?
In case you do for some reason need to deploy node_modules for some reason, you can in general do so. The message is quite clear - don't send filenames with # or ? in them. Those are not valid filenames per the HTTP spec - # is for designating anchors, and everything after the # is used client-side and thus won't map correctly to your file. ? is for denoting query string parameters and similarly won't work as you're intending to read the file whose name contains ? but rather cutting off the filename that the server will (attempt to) serve, before the ? character.
Related
According to How does AOSP 9.0 build system link the executable? and What does # mean in this clang command in AOSP build log? , when linking a module, AOSP seems to produce a .rsp file that contains all the obj files that the module need,and pass the file name as a parameter to the link command, for example:
prebuilts/clang/host/linux-x86/clang-4691093/bin/clang++ /OpenSource/Build/Android/9.0.0_r30/soong/.intermediates/bionic/libc/crtbegin_so/android_x86_64_core/crtbegin_so.o #/OpenSource/Build/Android/9.0.0_r30/soong/.intermediates/frameworks/base/libs/hwui/libhwui/android_x86_64_core_shared/libhwui.so.rsp ......
But the .rsp files seems to be removed after build.
The question is, how are these file generated and how to get these files? This may require to learn and modify the build scripts which is out of reach for me.
There maybe the answer for you, read the ninja build manual , in that manual .rsp file mentioned.
https://ninja-build.org/manual.html
the following is info that I copy out.
rspfile, rspfile_content
if present (both), Ninja will use a response file for the given command, i.e. write the selected string (rspfile_content) to the given file (rspfile) before calling the command and delete the file after successful execution of the command.
This is particularly useful on Windows OS, where the maximal length of a command line is limited and response files must be used instead.
My question is, how should my Erlang app reliably find a binary in the priv directory, not just in production; when installed properly, but during common test?
I realised today when I added a travis-ci configuration to an old Erlang app and pushed it to git-hub, that the process by which it works locally for me, is a little more fragile than I thought. The travis-ci build failed because it, not unreasonably, checked out my repo into a directory named after the repo, which is of the form erlang-APP. Locally my app is in a directory called APP-VSN though.
The result of this is that a call to code:lib_dir(APP) returns a correct result during the common test run locally, but if I rename my current directory to erlang-APP instead of APP-VSN (or just APP works too) my local build fails, just like it does for travis-ci, because code:lib_dir(APP) returns {error,bad_name}. The behaviour as though .. is added to the library path for rebar ct.
Renaming my github repo from erlang-APP to APP resolves the travis-ci build failure... but knowing the build tests only pass depending on the name of the directory the repo is checked out into doesn't sit right with me.
One way could be to use a soft link (either in the repo under version control, or created when initializing the tests), and make your Erlang code path go via the link. E.g., "./APP" -> ".", or "./lib/APP" -> "..".
I use electron-builder to build my app and succeed to build the first version which contains three outputs: foosetup.exe, foo-0.0.1-full.nupkg and RELEASES.Now I want to implement the auto-update and I have deployed a back-end service by using electron-release-server.
The auto-update need to set a feedURL which will be used to fetch updates,but the problem is that I don't know what the updates exactly means?Is it the foo-0.0.1-full.nupkg or the foo-0.0.1-delta.nupkg or another file?
The second problem is that I don't know how to create the delta file.I can just find an option remoteReleases in electron-builder which is a URL to your existing updates.If given,these will be downloaded to create delta file.But what's the URL exactly means?I find a example i which "remoteRelease": "https://github.com/user/repo"，and it creates some releases and uploads many extra files for each release such as foosetup.exe, foo-xx-full-nupkg, RELEASES.I guess electron-builder will fetch the ${remoteReleases/release/download/some-version/xxx} to download file and then diff the two file to create delta file,but I can't upload RELEASES when I create release on github,it reports that they don't support this file type.
Is there anyone can help?There're to few docs to follow for a beginer
For electron-release-server please take a look at the docs.
The delta-file will be create automatically if you use electron-builder. But in order for this to work remoteReleases must be set to a valid (and reachable) URL plus there must at least an empty file called RELEASES. So for the very first build just create an empty file and call it RELEASES.
On every future build there will be a RELEASES file created for you. Threw all the generated files in your release server (overwrite existing RELEASES) and it'll be fine.
Attention: For electron-release-server you do not need the RELEASES generated by electron-builder. electron-release-server will create one by itself.
To get started with auto-updates I'd recommend that you set up a dead-simple release-server locally. I. e.:
Create a directory and throw an empty file RELEASES in there.
Then start a simple webserver pointing at that directory (e. g. cd into/your/dir && php -S 0.0.0.0:80).
Edit your package.json: "remoteRelease": "http://localhost"
Then build your installer: npm run dist
It should successfully build and you should see some GET requests on your local server.
Take the generated files and stuff them into the directory you created.
Now increment your version and start another build: npm run dist
You should see some GET requests again and there should be an addition delta-file being created.
Again stuff all those things into the directory (or for electron-release-server upload the assets .nupkg, .exe and delta into a new release).
Hope that helps. Feel free to comment if something is unclear.
Check out this sample app that I have created https://github.com/electron-delta/electron-sample-app
It uses two npm packages.
#electron-delta/builder
#electron-delta/updater
More details https://github.com/electron-delta/electron-delta#installation
I am trying to deploy a .NET-MVC-application to Azure via Github, but deployment fails with the following error message. What could be the reason for that? It works locally.
WebCompiler: Begin compiling compilerconfig.json
D:\home\site\repository\src\BeYourMarket.Web\Themes\Default\Content\theme.less : WebCompiler error 0: The system cannot find the path specified. [D:\home\site\repository\src\BeYourMarket.Web\BeYourMarket.Web.csproj]
D:\home\site\repository\src\BeYourMarket.Web\Themes\Default\Content\theme.less : WebCompiler error 0: [D:\home\site\repository\src\BeYourMarket.Web\BeYourMarket.Web.csproj]
WebCompiler: Done compiling compilerconfig.json
Failed exitCode=1, command="D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "D:\home\site\repository\src\BeYourMarket.Web\BeYourMarket.Web.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="D:\local\Temp\8d34cc45ff19d01";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="D:\home\site\repository\src\\"
An error has occurred during web site deployment
Thank you in advance for any tipps and hints!
This is a current open issue with WebCompiler project. The Azure file system is locked down in ways that your local environment are not. Even though the file exists at the path on the server, the deployment script cannot read it.
In scanning the comments on the Issue (https://github.com/madskristensen/WebCompiler/issues/146), there doesn't seem to be a solution at this time except to pre-compile your CSS and include it in your repository.
In the end I dealt with it the following way:
Install package LessMsbuildTasks
Remove the file (in my case theme.less) from webcompile (right click on that file: Web Compiler - Remove file)
Add Dotless as build action for that file (right click on that file: Properties - Build action)
Commit changes and push
The next two steps are optional:
Put compilerconfig.json on .gitignore
Add that file to Web compiler again (right click on that file: Web Compiler - Compile file)
That way I can still use the constant compiling to develop and push it to my repository to initiate CI on Azure.
In my vNext-build-definition I added a new build step: "cURL Upload Files". After a little while playing around with the syntax of the URL and optional arguments I finally accomplished it to reach my sftp-server in the right target folder - the connection works so far.
But when cURL tries to start the upload the log simply says:
curl: Can't open 'my-Subfolder/Another Subfolder/myfile.txt'!
curl: try 'curl --help' or 'curl --manual' for more information
Unexpected exitcode 26 returned by tool curl.exe
With "buggy" I mean the way of selecting files in the definition of the build step without any assistance for the user: Try 1:I can easily select files over the "..."-button - I can browse the folder-structure of my repository and select a file. Feels very normal. The folder is then written into the textbox "Files" - but without double-quotes although it contains spaces... This runs into an error because cURL does expectedly not understand the folder Name.Try 2:
Then I added the double-quotes by myself, but still I get the error above.Try 3:
Then I tried the syntax **/myfile.txt
Ahaa, this actually works!!... but this uploads all files in all folders that are named myfile.txt (the log tells me something interesting: curl is called by using another syntax with curly brackets: {"complete-path/to/my/filename"})
just in case somebody of the tfs-dev-team reads this: Another senseless link is "More Information" at the bottom of the step definition. It leads to a topic "Deploy: Azure PowerShell" - that has nothing to do with FTP-Uploads and it´s content is just "This topic hasn't been written yet.." :-(
So, I ended up now with the following possibilities:
1. Use the syntax **/filename (if you can live with the drawback that all files in all subfolders of the repo with the same filename will be uploaded, so better keep your filenames unique!)
2. Use another build step before and copy or move the file into the root folder of the repo, in order to use the file name only in the "Files"-TextBox without path information.
3. Forget cURL-build-steps: Use WinSCP with a temporary script and run it with a batch-script-step(http://winscp.net/eng/docs/guide_automation) :-)
(The above mentioned syntax with curly brackets is useless for me because it forces me to have the whole path on the build agent included, I cannot use a relative path within my repo.)
Any better ideas?
I could reproduce your scenario on my side with TFS 2015 update1 + curl 7.47.0:
If the folder contains spaces, like Another Subfolder in your scenario, curl can't recognize it, we'll get error: curl: Can't open 'C:/agent/_work/xx/s/Another'!
If we use syntax **/myfile.txt, we'll get all files in workspace that are named myfile.txt.
But if we put the files under the folder whose name doesn't contain spaces, we won't get the error curl: Can't open 'C:/agent/_work/xx/s/Another'!, so you may consider create a new folder like AnotherSubfolder and put the files need to be copied under this folder, then you can use the whole path.