I'm trying to use dotnet-warp as a global tool in my .NET Core Travis-CI build, because I like the idea of a single executable so much better than a folder full of 75ish files.
I can successfully add the tool and verify there's a tools/dotnet folder in the $PATH...
But the log indicates that because .NET Core has been added recently, I'll need to restart or logout before I can actually use the tool.
Is anyone aware of a way to make this work in the Travis-CI environment?
Ran into the same issue, using the info from the Travis CI Installing Dependencies page and this comment on an issue about it, adding the following following to to my .travis.yml solved the problem:
before_script:
- export PATH=$PATH:/home/travis/.dotnet/tools
My build log:
$ export PATH=$PATH:/home/travis/.dotnet/tools
$ dotnet tool install -g dotnet-warp
You can invoke the tool using the following command: dotnet-warp
Tool 'dotnet-warp' (version '1.0.9') was successfully installed.
The command "dotnet tool install -g dotnet-warp" exited with 0.
$ cd ./src/[my project]/
The command "cd ./src/[my project]/" exited with 0.
$ dotnet-warp
Running Publish...
Running Pack...
Saved binary to "[my project]"
The command "dotnet-warp" exited with 0.
Related
I am trying to run API Manager 4.0.0 from source code, I download product-am and carbon-apimgt from github. How can i debug source code in idea or eclipse ?
First of all, you have to build the product. Follow these steps in order to build the product locally.
Make sure you have installed Java and Maven in your machine.
Download or clone carbon-apimgt repository from
https://github.com/wso2/carbon-apimgt.
Go to carbon-apimgt directory and run mvn clean install command in the terminal. (You can ignore unit tests by running mvn clean install -Dmaven.test.skip=true)
Copy the build version to the clipboard (ex:- 9.12.3-SNAPSHOT)
Download or clone product-apim from https://github.com/wso2/product-apim
Replace the value of carbon.apimgt.version in pom.xml file with the value you copied. (ex:- <carbon.apimgt.version>9.12.3-SNAPSHOT</carbon.apimgt.version>)
Go to product-apim directory and run mvn clean install command in the terminal. (You can ignore integration tests by running mvn clean install -Dmaven.test.skip=true which will save your time)
The built pack can be found in product-apim/modules/distribution/product/target directory.
After building the pack, extract the content in the zip file and run sh bin/api-manager.sh --debug 5005 command.
I recommend JetBrains Intellij IDEA to debug the code easily. So, open the carbon-apimgt project in IDEA. Then Add Configuration > Add new... > Remote JVM Debug > OK. After adding the configuration, you can click on the debug button and start debugging.
I am trying to add an extension in the jupyter lab. I go to extensions tab and click "install" on the extension. After a few seconds i get a pop up saying Build failed with 500, please run 'jupyter lab build' on the server for full output
could anyone tell me how to resolve it or find the logs related to that error atleast.
Using terminal, try jupyter lab build, which will produce an output on your AppData\Local\Temp folder (if you are on Windows). The log file will give more info on what is causing the failure during the build.
I had the same issue and npm dependencies were the culprit. I have updated conda with conda update -n base -c defaults conda and and yarn with conda install yarn and it solved the issue for me.
Also try looking at this one Jupyter Labs: “RuntimeError: npm dependencies failed to install” When Building.
For me this was fixed by pinning down a lower version of nodejs.
conda install -c conda-forge 'nodejs<16.14' did the trick. My resolution steps:
Install an environment from scratch conda create -c conda-forge -n <your_env_name> 'python>=3.8,<3.11' 'jupyterlab>=3.10'
Then attempt a nodejs install for example conda install -c conda-forge 'nodejs<16.14'
Attempt to build with jupyter lab build in terminal.
It's currently May 2022. Please note versions change a lot and very fast, when you face this same issue :)
On the UI (User Interface) of Jupyter Lab you see
Build failed with 524, please run 'jupyter lab build' on the server for full output
You open a console and run
jupyter lab build
Which ends with
An error occurred.
RuntimeError: JupyterLab failed to build
See the log file for details: /tmp/jupyterlab-debug-2znox977.log
Inside the log you see
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Run again
jupyter lab build --minimize=False
This completes successfully.
Explanation:
dev-build: This option controls whether a dev or a more streamlined production build is used. This option will default to
False (i.e., the production build) for most users. However, if you
have any labextensions installed from local files, this option will
instead default to True. Explicitly setting dev-build to False
will ensure that the production build is used in all circumstances.
minimize: This option controls whether your JS bundle is minified during the Webpack build, which helps to improve JupyterLab's overall
performance. However, the minifier plugin used by Webpack is very
memory intensive, so turning it off may help the build finish
successfully in low-memory environments.
In my case, the VM (Virtual Machine) had 3.75GB RAM and before crashing it was using ~3GB (you can see with htop in another console/terminal [image below]).
I'm trying to build a Release pipeline that is triggered by a new version of a published dotnet core tool. The trigger works fine, but I'm unable to install and run the tool in my Tasks.
CURRENTLY:
Running a Command Line Task results in a 401:
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json. [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
The tool package could not be restored.
Tool 'myapp' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
This leads me to believe that I'm missing something here, making it more complicated than it needs to be, or thinking about this the wrong way. The tools in the feed can be installed locally, so I believe it's my release approach.
I'm currently looking into Personal Access Tokens (PAT)
PREVIOUSLY:
If I use the .Net Core task and the custom option:
The logs show a malformed command passed to dotnet.exe:
[command]"C:\Program Files\dotnet\dotnet.exe" "dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
or
[command]"C:\Program Files\dotnet\dotnet.exe" "tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
I've tried varying arguments and I tend to always see the same error message:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Your custom dotnet command is quoted and dotnet is repeated : dotnet.exe" "dotnet tool install ..." so the command is misinterpreted.
You can use the Command Line task and set the dotnet command directly :
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
Using the .Net Core task works perfect for us.
Since the dotnet command is quoted, you need to set tool as the command and update into arguments. NuGet credentials can be provided with NuGet Auth task if needed.
Here is my walkaround:
I firstly published my private dotnet tool nupkg file also as an universal package to the same Azure Artifacts feed.
I was able to then use Universal Package task to download the .nupkg file into $(System.DefaultWorkingDirectory)/nupkgs/. This task will handle the authorization to Azure Artifacts feeds.
steps:
- task: UniversalPackages#0
displayName: 'Download mytool.cli.universal'
inputs:
downloadDirectory: '$(System.DefaultWorkingDirectory)/nupkgs/'
vstsFeed: '63d4aa2f-3ae7-4c27-8c18-aa8e3a9ff353'
vstsFeedPackage: '916d9a27-2c07-4071-8631-377f2ac08ed7'
vstsPackageVersion: 0.2.0
I then had the DotNetCoreCLI task to install my nupkg locally in agents.
steps:
- task: DotNetCoreCLI#2
displayName: 'Install mytool as a dotnet tool'
inputs:
command: custom
custom: tool
arguments: 'install --global mytool.CLI --add-source ./nupkgs --version 0.2.0'
You need to add the nuget authenticate task before you try to access the nuget feed
I'm installing dotnet core on Linux ARM64 using tarball as explained here. After installing I followed the suggestion to set DOTNET_ROOT=$PATH:$HOME/dotnet. However global tools fail with A fatal error occurred, the required library libhostfxr.so could not be found.
I fixed by changing the env variable to DOTNET_ROOT=$HOME/dotnet.
Is this a bug in the docs ?
Yes, this appears to be a bug in the documentation. The code which interprets DOTNET_ROOT does not split the string on :. DOTNET_ROOT should be set to an absolute file path which points to the directory containing the dotnet executable. If dotnet is on your PATH already, you can set it like this in bash/zsh.
export DOTNET_ROOT="$(dirname $(which dotnet))"
came across this problem while working on porting .net libraries from Windows to Raspberry PI. On the Raspberry the .net core 3.1 installs in /opt/dotnet, and that's where DOTNET_ROOT ought to point at:
export DOTNET_ROOT="/opt/dotnet"
This should eliminate the "fatal error occurred. The required library libhostfxr.so could not be found." error when attempting to run portable code using the 'dotnet' command on the RPI
I was getting an error trying to execute the dotnet ef from the EF cli global tools install.
Added this to the bottom of my /home/<user>/.bashrc worked for me.
# User specific aliases and functions
export DOTNET_ROOT=$HOME/.dotnet
export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools
Then the dotnet ef command worked correctly.
I had to add this to my ~/.zshrc
export DOTNET_ROOT=~/.dotnet
export PATH=$PATH:$DOTNET_ROOT
I found that I had different locations for different sdk/runtime versions. One was installed at "/home/{username}/.dotnet" and the other at "/usr/share/dotnet".
I found a post stating the default DOTNET_ROOT is "/usr/share/dotnet" and errors showed dotnet command was executing this location. I copied all files from "home/{username}/.dotnet" to "/usr/share/dotnet" with rsync.
sudo apt install rsync;
sudo rsync -a /home/{username}/.dotnet/ /usr/share/dotnet
I know how to package and then deploy meteor application. But recently for one project i'm stuck at an error which i couldn't resolve.
Steps I followed for package and deploy of my meteor app:
1. meteor build package
2. cd package
3. tar -xf inventoryTool.tar.gz
4. cd bundle/programs/server
5. npm install
6. cd ../..
7. PORT=<port> MONGO_URL=mongodb://127.0.0.1:27017/dbName ROOT_URL=http://<ip> node main.js
Here is the log for the error when i run the npm install(STEP 5) command.
Is there anything missing in my execution?. I'm not using the fibers package anywhere in my project. Does anyone have solution to this problem? Thanks in advance.
Why this happens (a lot)?
Your local version of node is v8.9.4. When using the build command, you will export your application and build the code against this exact node version. Your server environment will require this exact version, too.
An excerpt from the custom deployment section of the guide:
Depending on the version of Meteor you are using, you should install
the proper version of node using the appropriate installation process
for your platform. To find out which version of node you should use,
run meteor node -v in the development environment, or check the
.node_version.txt file within the bundle generated by meteor build.
Even if you don't use fibers explicitly it will be required to run your Meteor app on the server correctly.
So what to do?
In order to solve this, you need to
a) ensure that your local version of node exactly matches the version on the server
b) ensure that you build against the server's architecture (see build command)
To install a) the very specific node version on your server you have two options:
Option I. Use n, as described here. However this works only if your server environment uses node and not nodejs (which depends on how you installed nodejs on the server).
II. To install a specific nodejs version from the repositories, you may do the following:
$ cd /tmp
$ wget https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/nodejs_8.9.4-1nodesource1_amd64.deb
$ apt install nodejs_8.9.4-1nodesource1_amd64.deb
If you are not sure, which of both are installed on your server, check node -v and nodejs -v. One of both will return a version. If your npm install still fails, check the error output and if it involves either node or nodejs and install the desired distribution using the options above.
To build b) against the architecture on your server, you should use the --architecture flag in your build command.