I used to have a file named .netlify which didn't work after their cli update.
Now it created this folder and file. The problem is that when I do netlify deploy it always asks for the deploy path even though I have it in the configuration...
any ideas?
.netlify/state.json:
{
"path": "dist",
"siteId": "..."
}
The Nelify CLI looks for settings locally from two spots as stated in the docs
Flags
netlify deploy --dir dist
netlify.toml File (in project root)
[build]
publish = "dist"
NOTE: They will search in that order, so the command line flags will override what is in the netlify.toml file. Make sure you are using the latest version of the CLI.
Related
I'm attempting to deploy a python server to Google App Engine.
I'm trying to use the gcloud sdk to do so.
It appears the command I need to use is gcloud app deploy.
I get the following error:
me#mymachine:~/development/some-app/backend$ gcloud app deploy
ERROR: (gcloud.app.deploy) Error Response: [3] The directory [~/.config/google-chrome/Default/Cache] has too many files (greater than 1000).
I had to add ~/.config to my .gcloudignore to get past this error.
Why was it looking there at all?
The full repo of my project is public but I believe I've included the relevant portion.
I looked at your linked repo and there aren't any yaml files. As far as I know, a GAE project needs an app.yaml file because that file tells GAE what your runtime is so that GAE knows how to deploy/run your code. In fact, according to the gcloud app deploy documentation, if you don't specify any yaml files to be deployed, it will default to app.yaml in the current directory. If it can't find any in the current directory, it will try to build one.
Your repo also shows you have a Dockerfile. GAE documentation for custom runtimes says ...Custom runtimes let you build apps that run in an environment defined by a Dockerfile... In the app.yaml file for custom runtimes, you will have the following entry
runtime: custom
env: flex
Since you don't have an app.yaml file and you have a Docker file in which you are downloading and installing Chrome, it seems to me that gcloud app deploy is trying to infer your runtime and this has led to it executing some or all of the contents of the Dockerfile before it attempts to then push it to Production. This is what is making it take a peek at the config file on your local machine till you explicitly tell it to ignore it. To be clear, I'm not 100% sure of this, just trying to see if I can draw a logical conclusion.
My suggestion would be to create an app.yaml file and specify a custom runtime. Or just use the python runtime with flex
I am trying to deploy next.js app on Firebase hosting. But I don't understand which files to push to the server. When I run npm run build and pushed the build folder to firebase. But gives error that No index.html file found.
Here is the image of output of build folder. I have just created a simple component for testing purposes.
Output of build command
Check this out first. This is the official example provided by the Next.js team in their GitHub repo.
The idea behind the example:
The goal is to host the Next.js app on Firebase Cloud Functions with Firebase Hosting rewrite rules so our app is served from our Firebase Hosting URL. Each individual page bundle is served in a new call to the Cloud Function which performs the initial server render.
This is based off of the work at https://github.com/geovanisouza92/serverless-firebase and https://github.com/jthegedus/firebase-functions-next-example as described here.
PS : I know posting links as answers is not the best way, but my rep power is not enough to put this as a comment.
On package.json you need to add npm scripts for building and exporting like.
"scripts": {
"dev": "next",
"build": "next build",
"start": "next start",
"export": "next export"
},
And then you can run
npm run build && npm run export
Next build will build your project for shipping and export will put your files ready for hosting on a static hosting server (like firebase hosting).
npm run export
will create an out/ directory and place all your files there ready for uploading.
Note:
If your app needs to generate dynamic pages at the runtime, you can't
deploy it as a static app.
Read more
On package.json you need to modify build scripts.
"build": "next build && next export",
and on next.config.js you need to modify
/** #type {import('next').NextConfig} */
module.exports = {
images: {
loader: "imgix",
path: "https://noop/",
},
reactStrictMode: true,
}
execute npm run build and generate folder /out
Its a little long and messy process as everyone answered above.
I have requested firebase for Next JS integration here.
https://firebase.google.com/support/troubleshooter/report/features
If we all send request, then firebase will soon include react, next js ONE CLICK DEPLOY feature.
Thus we don't need to go to GitHub & Vercel & Firebase for one project.
I have a solution with some projects targeting .NET Standard 2.0 and a console application project targeting .NET Core 2.1.
I set "myFolder" as the output folder.
Building from Visual Studio, I get all DLL files in:
"myFolder\netstandard2.0"
"myFolder\netcoreapp2.1"
I get the same using the "dotnet build" command.
Now I need my console application's EXE file.
So I use the "dotnet publish -c Release -r win-x64 MySolution.sln" command.
Now I get this new directory, "myFolder\netcoreapp2.1\win-x64", where I find all DLL files and the console application's EXE file.
Not enough!
I find one directory more, "myFolder\netcoreapp2.1\win-x64\publish", where I find again all DLL files and the console application's EXE file.
Which meaning do they have? I read the command documentation, but I didn't find my answer.
Per the documentation
-o|--output <OUTPUT_DIRECTORY>
Specifies the path for the output directory. If not specified, it defaults to ./bin/[configuration]/[framework]/publish/ for a framework-dependent deployment or ./bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained deployment.
dotnet publish -c Release -r win-x64 --output ./MyTargetFolder MySolution.sln
All you really need to understand to be able to successfully publish and deploy is that you need to dotnet publish and ensure that you have a Release configuration -c Release, as well as any other required options on the command line.
All of your files will be in the 'publish' subfolder, e.g. ./bin/Release/[framework that your solution is targeting]/publish. The files contained here are everything that is needed for a running instance of your application/service. The MySolution.dll is the entry point for your app/service, and will automatically link to all of the other dependencies and configuration stored in the publish folder.
To configure and deploy a running instance, you need to work out how to deploy all of those files to a server, and somehow configure something (e.g. a web server, runtime, service host ...) to call your MySolution.dll.
Note that in your dotnet publish you're specifying -r, which means that your application is targetted to run under 64 bit Windows, as opposed to a Linux distribution or OS X (which makes it less portable, but it has the advantage of isolating your application from changes to an installed runtime on a server that you deploy it to.). That's why you're seeing an extra folder win-x64.
Also you're explicitly building from the solution configuration specified by your solution file MySolution.sln, which is probably the most reliable thing to do as this will ensure that any projects used as dependencies by your solution (which is a typical good practice) will be included in the build/publish.
I have multiple .csproj files in my git source folder and its subfolders. I want to create NuGet packages for all of them. If I understand things correctly, I should add NuGet Packager build step and configure its Path to csproj or nuspec file(s) to pack to be
**\*.csproj
But no packages get created when I run my build.
By the way, if I manually select some 'csproj' file using "..." button and run build then package for it will be created.
Could anyone explain why I cannot use **\*.csproj matching pattern to create packages for all projects in my source directory and its subdirs? Is there any limit for nesting level or something? At least I have couple csproj files on maximum nested level 4-5 counting from the source folder...
p.s. I know there was a similar bug about Exclusion pattern not working for vsts build so I wonder if it's a related issue?
See my build configuration and log of my NuGet Packager and NuGet Publisher build steps where D:_work\3\s is the folder on a build server where it cannot find csproj files. Although I can see files there, for example the first is on D:_work\3\s\Source\Product\Components\Folder1\MyProj1.csproj, the second on D:_work\3\s\Source\Product\Components\Folder2\MyProj2.csproj, etc...
The level of nesting should not be an issue. I was able to setup a test project with 3 Projects at various levels and the single NuGet Task created a NuGet package for all of them.
Here is the configuration I used (It is the default configuration at this point in time). This was done using version 2.x of the task, so if you are using an earlier version you may want to upgrade.
You can also watch exactly what is happening during this step by setting system.debug = true when you queue the build. After you do this, you can look into the log for the Nuget Pack step and you should see it iterating through all of your directories and sub-directories and flagging those that match. Here you can see that it found and then continues to pack these 3 projects.
Post your detailed setup and log here if you still need additional assistance.
I had a similar issue. The NuGet Pack task finishes successfully, but didn't create a NuGet package.
In the task logging (when running with debug=true) I see the following:
...
##[debug]found 8037 paths
##[debug]applying include pattern
##[debug]0 matches
...
The NuGet Pack task doesn't create a package because it didn't find any .csproj or .nuspec file. In my case the reason it didn't find any .csproj or .nuspec file is because the work folder of my build agent is set to ".". I found this when analysing the pattern in the logs of the NuGet Pack task.
...
##[debug]pattern: 'D:\Agents\agent_1\.\123\s\*.nuspec'
...
The fix for this issue is changing the workFolder in the .agent file of the build agent. You can find this in the root folder of the build agent (e.g. D:\Agents\agent_1\.agent). Originally this was:
{
"agentId": 48,
"agentName": "agent_1",
"poolId": 3,
"serverUrl": "<TFS url>",
"workFolder": "."
}
And you have to change it to
{
"agentId": 48,
"agentName": "agent_1",
"poolId": 3,
"serverUrl": "<TFS url>",
"workFolder": "D:\\Agents\\agent_1"
}
Be sure to restart the build agent windows service after changing this file!
Hope this helps :-)
I've set up the Docker Deployment plugin on PyCharm, however, on hitting play, the Deploy log shows a failure with:
Could not open requirements file: [Errno 2] No such file or directory: 'environments/dev/requirements.txt'
I assume that this has something to do with the docker build context that is part of the Docker Deployment plugin. I've confirmed that there is in fact a requirements.txt file in the environments/dev/ directory inside the root of my PyCharm project. Does anyone know how to specify the docker build context/path in PyCharm or the Docker Deployment plugin?
UPDATE:
By adding RUN ls -l to the Dockerfile, I was able to deduce that the plugin is running from the same directory as the Dockerfile. Still looking for a way to specify the build path if it's at all possible.
My current solution to this problem is to move the Dockerfile to the root directory of my PyCharm project so that when ADD . /var/app is run, it copies over the correct files. As I mentioned in the "UPDATE", the PyCharm plugin uses the directory the Dockerfile is run from as the build context/path.
Would still like to be able to specify the build path, but this may be the best solution given the limitations of the plugin.