I have successfully compiled my nuxt3 project locally. But the deployment is not working with cloud flare page
00:14:35.140 Executing user command: npm run generate
00:14:35.613
00:14:35.613 > generate
00:14:35.613 > nuxt generate
00:14:35.614
00:14:35.725 Nuxt CLI v3.0.0-rc.3-27567768.c1f728e
00:14:38.919 ✔ Using ~/components/content for components in Markdown
00:14:43.437 ℹ Vite client warmed up in 3072ms
00:14:44.646 ℹ Client built in 4280ms
00:14:44.681 ℹ Building server...
00:14:47.053 ✔ Server built in 2373ms
00:14:47.249 ✔ Generated public dist
00:14:47.249 ℹ Initializing prerenderer
00:14:50.871 ℹ Prerendering 4 initial routes with crawler
00:14:50.891 ├─ / (20ms)
00:14:50.894 ├─ /200 (3ms)
00:14:50.897 ├─ /404 (3ms)
00:14:50.958 ├─ /api/_content/cache (61ms)
00:14:50.971 ✔ You can now deploy .output/public to any static hosting!
00:14:51.017 Finished
00:14:51.018 Note: No functions dir at /functions found. Skipping.
00:14:51.018 Validating asset output directory
00:14:51.018 Error: Output directory ".output/public" not found.
00:14:52.095 Failed: build output directory not found
This is failed with "Error: Output directory ".output/public" not found." but actually the directory is generated few lines before. Any clue to resolve this problem?
I worked around the problem with:
Adding Nitro output config [1] [2] to nuxt.config.ts:
export default defineNuxtConfig({
"nitro": {
"output": {
dir: 'output',
serverDir: 'output/server',
publicDir: 'output/public'
}
}
})
In Cloudflare Pages, setting build output directory to: server/output/public.
I think the issue is caused by the default deployment script at CloudFlare side, checking the existence of .output, but not being able to see "hidden" (starting with dot) folders.
17:27:08.682 Validating asset output directory
17:27:08.682 Error: Output directory ".output/public" not found.
Edit (2022-07-10) found a cleaner way:
add "target" : "static" to nuxt.config.ts
Use as CloudFlare Pages build command: ./node_modules/.bin/nuxt generate
Set CloudFlare Pages build output directory to dist
I also had this issue, after testings, this is what i found.
The documentation says Use the nuxi generate command to build your application. (https://v3.nuxtjs.org/getting-started/deployment#static-hosting).
Configure Node Version
First, i'll add an .nvmrc file at the root of the project, so that Cloudflare doesn't use its default 12.18.0 version on deploy.
The content of the file is :
16
sources:
nuxt 3 prerequisites : https://v3.nuxtjs.org/getting-started/installation/#prerequisites
Node version on Cloudflare Pages : https://developers.cloudflare.com/pages/platform/build-configuration/#language-support-and-tools
Configure the Cloudflare Page
Then i'm adding the configuration in the cloudflare interface with following :
Build command: npx nuxi generate
Build output directory: /.output/public
Root directory: /
🚀
Going further
Actually, it shouldn't be a problem to deploy easily on CF Pages: the team has added a cloudflare_pages preset right into nitro, the server library behind nuxt 3. https://nitro.unjs.io/deploy/providers/cloudflare#cloudflare-pages
I wasn't able to make this preset work for now, i'll update my answer when this has changed :)
I'm using dagster 0.11.3 (the latest as of this writing)
I've created a Dagster pipeline (saved as pipeline.py) that looks like this:
#solid
def return_a(context):
return 12.34
#pipeline(
mode_defs=[
ModeDefinition(
executor_defs=[dask_executor] # Note: dask only!
)
]
)
def the_pipeline():
return_a()
I have the DAGSTER_HOME environment variable set to a directory that contains a file named dagster.yaml, which is an empty file. This should be ok because the defaults are reasonable based on these docs: https://docs.dagster.io/deployment/dagster-instance.
I have an existing Dask cluster running at "scheduler:8786". Based on these docs: https://docs.dagster.io/deployment/custom-infra/dask, I created a run config named config.yaml that looks like this:
execution:
dask:
config:
cluster:
existing:
address: "scheduler:8786"
I have SUCCESSFULLY used this run config with Dagster like so:
$ dagster pipeline execute -f pipeline.py -c config.yaml
(I checked the Dask logs and made sure that it did indeed run on my Dask cluster)
My question is: How can I get Dagit to use this Dask cluster?
The only thing I have found that seems related is this:
https://docs.dagster.io/_apidocs/execution#executors
...but it doesn't even mention Dask as an option (it has dagster.in_process_executor and dagster.multiprocess_executor, which don't seem at all related to dask).
Probably I need to configure dagster-dask, which is documented here: https://docs.dagster.io/_apidocs/libraries/dagster-dask#dask-dagster-dask
...but where do I put that run config when using Dagit? There's no way to feed config.yaml to Dagit, for example.
Some options:
you can manually plug in the values that are in config.yaml in to the dagit playground
you can bind the config directly to the executor if you do not need to change it ever https://docs.dagster.io/concepts/configuration/configured#configured-api
you can create a preset from that config yaml https://docs.dagster.io/tutorial/advanced-tutorial/pipelines#pipeline-config-presets
Given the context, I would recommend the configured API
I would like to store all Salt files (pillars, states, data files, etc.) in a git repository, so that this repository can be cloned on several different deployments.
Then I would like to be able to change the value of some pillar settings, such as a pathname, or a password, but without editing the original file which is in version control (i.e. those modifications would be local only and not necessarily versioned).
I would like to be able to pull new versions from the original repository (e.g. to add new pillar and state definitions) without losing the customized values.
E.g. the "base" or "default" pillar file would have settings like:
service:
dir: /var/opt/myservice
username: myuser
password: mypassword
and I would like to customize some settings, in another file, without changing the base file:
service:
dir: /mnt/data/myservice
password: secret_password
The modified settings should take precedence over the base / default ones.
Is it possible to do this by using environments (e.g. a "base" environment and a "custom" environment)?
Or perhaps by including these custom pillar files?
The documentation seems to indicate that there isn't a fixed order for overriding pillar settings.
Let me first suggest a way where you keep the original file and the customized settings in the git repository. See below how to override setting with a file outside of git.
Setup Git Pillar
I assume all files are stored in a git pillar like described here. I am using the syntax of salt version 2015.8 here.
ext_pillar:
- git:
- master https://gitserver/git-pillar.git:
- env: base
In your top.sls file you can list different SLS files. They will override each other in the order listed in the top file:
# top.sls
base:
'*':
standard
'*qa'
qaservers
'hostqa':
hostqaconfig
This will apply on all servers:
# standard.sls
test:
setting1: A
setting2: B
This will apply on all servers with the name ending with 'qa':
# qaservers.sls
test:
setting2: B2
This will apply to the server with the name 'hostqa':
# hostqa.sls:
test:
setting1: A2
The commands salt hostqa saltutil.refresh_pillar and salt hostqa pillar.data will then show that the values A2 and B2 as they have all been merged together.
As this works without specifying environments, I suggest not to use environments here.
Override some local settings outside of Git
To override some of your settings locally, you can add another external pillar. One of the most simple ones is cmd_yaml that will run a command (here: cat) and merge the output with the current pillar:
ext_pillar:
- git:
- master https://gitserver/git-pillar.git:
- env: base
- cmd_yaml: cat /srv/salt/local_override.sls
All external pillars are executed in the order listed in the configuration file.
I have a Play server application.
Currently, I have 20-line bash script that creates this deb:
/srv
/foo
/conf
<unmanaged resources>
/staged
<jars>
I'd like to use sbt native packager to generate this.
Currently, sbt debian:package-bin gives me
etc/
default/
foo
foo
init/
foo.conf
usr/
bin/
foo
share/
foo/
bin/
foo
conf/
<unmanaged resources>
lib/
<jars>
share/
doc/
api/
<docs>
logs
README
var/
log/
foo/
How do I do I get my desired layout? Do I need to implement an archetype?
I'm using SBT 0.13.7 and SBT native packager 1.0.0-M1.
If your layout is close to the one already generated, you could use settings like defaultLinuxInstallLocation and defaultLinuxConfigLocation.
Or modify linuxPackageSymlinks and linuxPackageMappings directly, something like
linuxPackageSymlinks := Seq(),
linuxPackageMappings := {
val libPath = "/srv/foo/staged"
val libs = scriptClasspathOrdering.value.map { case (file, classpath) =>
file -> classpath.replaceFirst("^lib", Matcher.quoteReplacement(libPath))
}
Seq(LinuxPackageMapping(libs))
// plus configuration
},
If you have lots of binaries to archive (i.e. you have lots of dependencies), debian:packageBin is pretty slow. For debugging, consider using debianExplodedPackage.
Also, know that whatever is in the directory debianExplodedPackage will get included in the archive, so if there's extra stuff in the .deb at the end, you may need to delete that directory.
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.