I'm trying to use nix for building dotnet (sdk 5) projects.
The configuration is something like
stdenv.mkDerivation {
# builder = "${bash}/bin/bash";
# args = [ ./builder.sh ];
name = "mypackage";
src = ./.;
HOME = "/tmp/test-home";
DOTNET_CLI_TELEMETRY_OPTOUT = 1;
nativeBuildInputs = [ nodejs ];
buildInputs = [ dotnet openssl cacert ];
configurePhase = ''
export HOME=$PWD/home
runHook preConfigure
dotnet nuget list source
dotnet nuget locals all --list
dotnet restore
runHook postConfigure
'';
buildPhase = ''
export DOTNET_CLI_TELEMETRY_OPTOUT=1
export DOTNET_NOLOGO=1
${dotnet}/bin/dotnet publish ProjectDirectory --self-contained -r linux-x64 -c Release
'';
installPhase = ''
mkdir -p $out/
'';
};
The HOME attribute in argument for stdenv.mkDerivation is for nix-shell only. Since nix-shell will inherit normal $HOME, I need to set $HOME to another empty directory to mimic behavior of build phase.
When using nix-shell and run dotnet restore manually, it works fine.
When using nix-build, build failed with following error when running dotnet restore
Registered Sources:
nuget.org [Enabled]
https://api.nuget.org/v3/index.json
http-cache: /build/PROJECTNAME/home/.local/share/NuGet/v3-cache
global-packages: /build/PROJECTNAME/home/.nuget/packages/
temp: /build/NuGetScratch
plugins-cache: /build/PROJECTNAME/home/.local/share/NuGet/plugins-cache
Determining projects to restore...
/nix/store/fvfyn01fjmawvyn7vlhhrgkzyy6321wl-dotnet-sdk-5.0.202/sdk/5.0.202/NuGet.targets(131,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [/build/PROJECTNAME/PET-CT-machine-service.sln]
/nix/store/fvfyn01fjmawvyn7vlhhrgkzyy6321wl-dotnet-sdk-5.0.202/sdk/5.0.202/NuGet.targets(131,5): error : Name or service not known (api.nuget.org:443) [/build/PROJECTNAME/PET-CT-machine-service.sln]
/nix/store/fvfyn01fjmawvyn7vlhhrgkzyy6321wl-dotnet-sdk-5.0.202/sdk/5.0.202/NuGet.targets(131,5): error : Name or service not known [/build/tomopioneer/PET-CT-machine-service.sln]
What's the difference between nix-build and nix-shell --pure when HOME is manually set?
By reading code from github NixOS/nixpkgs repository, it seems several dotnet packages were using nuget manually and using dotnet restore with local source. Is that necessary?
I've make more tests about api.nuget.org.
running curl https://api.nuget.org/v3/index.json -v, I got:
works fine when directly run under terminal of nixos
works fine in nix-shell --pure
error in nix-build, curl: (6) Could not resolve host: api.nuget.org
nix-shell has network access which is not allowed in the sandbox that nix-build uses without a fixed output derivation.
By reading code from github NixOS/nixpkgs repository, it seems several dotnet packages were using nuget manually and using dotnet restore with local source. Is that necessary?
With sandbox enabled yes.
I am running a Debian 10 (Buster) Server for my Rails 6.0.3, Ruby 2.6.3, Mina 1.2.3 app. When I run Mina deploy it errors out but does not give me enough to help me understand what I need to do to resolve the issue.
Mina Deploy output
Precompiling asset files
$ RAILS_ENV="production" bundle exec rake assets:precompile
Traceback (most recent call last):
3: from /var/www/site/tmp/build-15965768145748/vendor/bundle/ruby/2.6.0/bin/ruby_executable_hooks:24:in `<main>'
2: from /var/www/site/tmp/build-15965768145748/vendor/bundle/ruby/2.6.0/bin/ruby_executable_hooks:24:in `eval'
1: from /usr/local/rvm/gems/ruby-2.6.3/bin/rake:23:in `<main>'
/usr/local/rvm/gems/ruby-2.6.3/bin/rake:23:in `load': cannot load such file -- /usr/local/rvm/rubies/ruby-2.6.3/lib/ruby/gems/2.6.0/specifications/default/exe/rake (LoadError)
! ERROR: Deploy failed.
Deploy.rb
require 'mina/bundler'
require 'mina/rails'
require 'mina/git'
require 'mina/rvm'
set :application_name, 'site'
set :domain, 'server'
set :user, 'deployer'
set :deploy_to, "/var/www/site"
set :repository, "git#github.com:git.git"
set :branch, 'master'
set :rvm_use_path, '/etc/profile.d/rvm.sh'
set :shared_files, fetch(:shared_files, []).push('config/database.yml', 'config/secrets.yml')
task :remote_environment do
ruby_version = File.read('.ruby-version').strip
raise "Couldn't determine Ruby version: Do you have a file .ruby-version in your project root?" if ruby_version.empty?
invoke :'rvm:use', 'ruby-2.6.3'
end
desc "Deploys the current version to the server."
task :deploy do
deploy do
invoke :'git:clone'
invoke :'deploy:link_shared_paths'
invoke :'bundle:install'
invoke :'rails:db_migrate'
invoke :'rails:assets_precompile'
invoke :'deploy:cleanup'
on :launch do
end
end
end
namespace :passenger do
desc "Restart Passenger"
task :restart do
queue %{
echo "-----> Restarting passenger"
cd #{deploy_to}/current
#{echo_cmd %[mkdir -p tmp]}
#{echo_cmd %[touch tmp/restart.txt]}
}
end
end
I have made sure that yarn is installed and working on my Production machine. When I run the precompile on the Production machine, it runs through successfully. But still errors out in the Mina Deploy with no change in the error text. I have looked into this article In doing so I have commented out the suggested code snippet just to test, but that did not change anything. In looking at my bashrc, I do not see any snippets with EXPORT or SOURCE at the beginning of them.
EDIT: When I run the precompile on the server side, each new deployment folder seems like it will give me this issue.
We are trying to update the schema of an Sqlite database during continuous integration. Here is a simplified version of our scenario.
The deployment script publishes the project.
cd App
App> dotnet publish <args>
That creates the following directory structure.
artifacts/
App.dll
Database.sqlite
The-rest-of-the-publish-output
web.config
App/
Migrations/
Program.cs
project.json
Startup.cs
The deployment script then runts the migrations.
App> dotnet ef
--assembly ..\artifacts\App.dll
--startup-assembly ..\artifacts\App.dll
database update
The issue is that we receive the following message:
Unexpected value '..\artifacts\App.dll' for option 'assembly'
We have also tried other ways to run dotnet ef database update on the compiled project but have not been able to determine how to update the database in the artifacts directory.
In our current scenario, we do it like this on Startup.cs:
if (migrateDb)
{
try
{
using (var serviceScope = app.ApplicationServices.GetService<IServiceScopeFactory>()
.CreateScope())
{
serviceScope.ServiceProvider.GetService<ApplicationDbContext>()
.Database.Migrate();
}
}
catch { }
}
while on development migrateDb resolves to false so we can add/remove and apply migrations as desired. On production that will resolve to true for convenience.
There may be well more valid/appropiate options, usually depends on the context and/or project needs. This is just one way of many.
I'm trying to deploy my ASP.NET 5 Beta 7 web application to Azure platform using Continuous Deployment on Visual Studio Online.
I've already follow these guides:
https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5 -> to deploy asp.net 5 web apps
http://www.brandonmartinez.com/2015/09/16/deploying-asp-net-5-beta-7-through-vso/ -> changes to previous guide to deploy asp.net 5 Beta 7 web apps
When I commit and push a changes, the build task triggers correctly but it fails when executing prepublish script of project.json:
"scripts": {
"prepublish": [ "npm install", "bower install", "gulp clean", "gulp min" ]
}
The error (warning) is:
npm WARN optional dep failed, continuing fsevents#1.0.0
I was able to deploy by enabling Continue on error option in the build definition and only for PublishLocal.ps1 step (that fails).
Visual Studio Online completes (partially) the build and deploy my site to Azure and everything seems to works without problems, but, what is that error? There is a way to fix it?
Here is my PublishLocal.ps1 step (from http://www.brandonmartinez.com/2015/09/16/deploying-asp-net-5-beta-7-through-vso/):
#Requires -Version 3.0
param($vsoProjectName, $projectName, $buildConfiguration, $buildSourcesDirectory)
$VerbosePreference = "continue"
&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}
$globalJson = Get-Content -Path $PSScriptRoot\global.json -Raw -ErrorAction Ignore | ConvertFrom-Json -ErrorAction Ignore
if($globalJson)
{
$dnxVersion = $globalJson.sdk.version
}
else
{
Write-Warning "Unable to locate global.json to determine using 'latest'"
$dnxVersion = "latest"
}
& $env:USERPROFILE\.dnx\bin\dnvm install $dnxVersion -Persistent
$dnxRuntimePath = "$($env:USERPROFILE)\.dnx\runtimes\dnx-clr-win-x86.$dnxVersion"
& dnu build "$PSScriptRoot\src\$projectName" --configuration "$buildConfiguration"
& dnu publish "$PSScriptRoot\src\$projectName" --configuration "$buildConfiguration" --out "$buildSourcesDirectory\$vsoProjectName\artifacts\bin\$buildConfiguration\Publish" --runtime "$dnxRuntimePath"
Without seeing your entire build log, it's a little difficult to diagnose. However, my assumption is that NPM is writing WARN messages to stderr. As such, the VSTS build server will see that as an error instead of a warning.
I would recommend either adding --quiet to your NPM scripts, or update your dependency to not throw the WARN. You could also changed the PowerShell script VerbosePreference to SilentlyContinue to see if that stops printing the message as well.
I am following this blog:
http://maplekeycompany.blogspot.se/2012/03/very-basic-cowboy-setup.html
In short, I am trying to compile an application with rebar just as the person in the blog.
Everything goes smoothly until I want to run the command:
./rebar get-deps compile generate
This then give me the following errors and warnings,
> User#user-:~/simple_server/rebar$ ./rebar get-deps compile generate
> ==> rebar (get-deps)
> ==> rebar (compile) Compiled src/simple_server.erl Compiled src/simple_server_http.erl src/simple_server_http_static.erl:5:
> Warning: behaviour cowboy_http_handler undefined Compiled
> src/simple_server_http_static.erl
> src/simple_server_http_catchall.erl:2: Warning: behaviour
> cowboy_http_handler undefined Compiled
> src/simple_server_http_catchall.erl WARN: 'generate' command does not
> apply to directory /home/harri/simple_server/rebar Command 'generate'
> not understood or not applicable
I have found a similar post with the same error:
Command 'generate' not understood or not applicable
I think the problem is in the reltool.config but do not know how to proceed, I changed the path to the following: {lib_dirs, ["home/user/simple_server/rebar"]}
Is there a problem with the path? How can rebar get access to all the src files and also the necessary rebar file to compile and build the application?
You need to make sure your directory structure and its contents are arranged so that rebar knows how to build everything in your system and generate a release for it. Your directory structure should look like this:
project
|
-- rel
|
-- deps
|
-- apps
|
-- myapp
| |
| -- src
| -- priv
|
-- another_app
The rel directory holds all the information needed to generate a release, and the apps directory is where the applications that make up your project live. Application dependencies live in the deps directory. Each app such as myapp and another_app under the apps directory can have their own rebar.config files. While two or more such applications are possible here, normally you'd have just one and all others would be dependencies.
In the top-level project directory there's also a rebar.config file with contents that look like this:
{sub_dirs, ["rel", "apps/myapp", "apps/another_app"]}.
{lib_dirs, ["apps"]}.
If necessary, you can use rebar to generate your apps from application skeletons:
cd apps
mkdir myapp another_app
( cd myapp && rebar create-app appid=myapp )
( cd another_app && rebar create-app appid=another_app )
If an application has dependencies, you'll have to add a rebar.config to its directory and declare each dependency there. For example, if myapp depends on application foo version 1.2, create apps/myapp/rebar.config with these contents:
{deps,
[{foo, "1.*", {git, "git://github.com/user/foo.git", {tag, "foo-1.2"}}}]
}.
When you run rebar get-deps, rebar will populate the top-level deps directory to hold all dependencies, creating deps if necessary. The top-level rebar.config can also declare dependencies if necessary.
You also need to generate a node, necessary for your releases:
cd ../rel
rebar create-node nodeid=project
You then need to modify the reltool.config file generated by the previous step. You need to change
{lib_dirs, []},
to
{lib_dirs, ["../apps", "../deps"]},
and just after the line {incl_cond, derived}, add {mod_cond, derived}, so that releases contain only the applications needed for correct execution.
Next, wherever the atom 'project' appears, you need to replace it with the applications under the apps directory. For our example, we'd change this part:
{rel, "project", "1",
[
kernel,
stdlib,
sasl,
project
]},
to this:
{rel, "project", "1",
[
kernel,
stdlib,
sasl,
myapp,
another_app
]},
and change this part:
{app, project, [{mod_cond, app}, {incl_cond, include}]}
to this:
{app, myapp, [{mod_cond, app}, {incl_cond, include}]},
{app, another_app, [{mod_cond, app}, {incl_cond, include}]}
You might also need to add the line:
{app, hipe, [{incl_cond, exclude}]},
to exclude the hipe application since sometimes it causes errors during release generation or when trying to run the release. Try without it first, but add it if you see errors related to hipe when generating a release, or if attempts to run the generated release result in this sort of error:
{"init terminating in do_boot",{'cannot load',elf_format,get_files}}
you'll need to add it.
With all this in place you can now execute:
rebar get-deps compile generate
and you should be able to successfully generate the release. Note that running rebar generate at the top level rather than in the rel dir will result in a harmless warning like this, which you can ignore:
WARN: 'generate' command does not apply to directory /path/to/project
Finally, you can run the release. Here's how to run it with an interactive console:
$ ./rel/project/bin/project console
Exec: /path/to/project/rel/project/erts-6.2/bin/erlexec -boot /path/to/project/rel/project/releases/1/project -mode embedded -config /path/to/project/rel/project/releases/1/sys.config -args_file /path/to/project/rel/project/releases/1/vm.args -- console
Root: /path/to/project/rel/project
Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:false]
Eshell V6.2 (abort with ^G)
(project#127.0.0.1)1>
or you could run ./rel/project/bin/project start to start it in the background. Run ./rel/project/bin/project with no arguments to see all available options.