I have a custom section in serverless.common.yml, which is common to all the services. Some services use some additional properties in their serverless.yml appart from the defined in the file mentioned before.
My idea would be to perform something like:
custom:
- ${file(../serverless.common.yml):custom}
- myServiceCustomProperty: 1
But this does not work. Any idea about how can I achieve that behaviour?
Thank you
- ${file(../serverless.common.yml):custom} is going to dump the array from common so that wont merge. With this approach you need to add each property from the common/custom section individually:
custom:
- foo: ${file(../serverless.common.yml):custom.foo}
- myServiceCustomProperty: 1
or
custom: ${file(../serverless.common.yml):custom}
Alternatively if your setup is complex you can write a serverless.js file instead which allows JS processing. I personally use that to programically merge a dozen yml file - for example when I run sls offline I want to add/remove a bunch of stuff so that's a pretty powerful approach.
Related
I'm trying to have a structure to run a dbt project, where I have multiple entities (bank, names, cars). I'm going to have exactly the same code for them all.
Based on that, I'm trying to have several folder with the same code, where I can define inside the dbt_project.yamlfile. The idea is something like this:
vars:
db_name: 'db_official'
staging:
bank: 'variable_bank'
car: 'variable_car'
name: 'variable_name'
The variable "db_name" works. So, my the two problems I'm having are:
How to have this structure inside the the yaml file?
How to reference this structure inside each file?
(extra) Any other ideas how to handle this?
Thanks!
vars are basically globals. They can be scoped to your whole project, or to a package within your project, but not more specifically than that (they share a flat namespace). See the docs.
I would pull out the common code into a macro, then call that macro from each model file, passing in the unique values as string literals in the model file:
-- models/staging/bank.sql
{{ my_model_template('variable_bank') }}
-- models/staging/car.sql
{{ my_model_template('variable_car') }}
I am trying to set up my serverless.yml file with only an API Gateway, and there are several resources that I need to reuse throughout the file, and I'd like to not copy and paste the same lines of code per resource like 100 times.
For example, I want to reuse TestId resource below and dynamically pass in the Ref under ParentId so I can reuse the resource for multiple parent resources. How can I do that?
TestResource:
Type: AWS::ApiGateway::Resource
Properties:
ParentId:
Fn::GetAtt:
- TestApi
- RootResourceId
PathPart: test
RestApiId:
Ref: TestApi
TestId:
Type: AWS::ApiGateway::Resource
Properties:
ParentId:
Ref: TestResource
PathPart: '{id}'
RestApiId:
Ref: TestApi
Ideally I would want the resuable TestId resource in a separate file and then reference it, and also pass in the dynamic value that I want to insert in. Something like:
TestId: ${file(testid.yml):TestId} somehow override the TestId.Properties.ParentId.Ref: <somevalue>
Does anyone know if this is possible?
In case you are using NodeJs (if not maybe something like this exists in your programming language), I think you should take a look at this plugin : https://www.npmjs.com/package/yamlinc
It allow to compose YAML files using $include tag.
Hope this helps you.
Is there any way to split the resource definitions in serverless framework into multiple files? Something like:
resources:
- ${resources/base.yml}
- ${resources/foo.yml}
I have been trying multiple combinations but I keep getting errors about references not being found.
Even though dashmug's answer is correct, I found that the way I was trying to make it work was quite close to a valid solution too. As explained in this github comment it is possible to reference other files in the resources section:
resources:
- ${file(resources/first-cf-resources.yml)}
- ${file(resources/second-cf-resources.yml)}
Provided that each those files defines a "Resources" key of its own, like:
---
Resources:
MyCFResource:
Type:.....
What I didn't manage is to have a mixed approach such as:
resources:
- ${file(resources/first-cf-resources.yml)}
- ${file(resources/second-cf-resources.yml)}
SomeResource:
Type: ...
So I just have a resources/base.yml for that instead.
I can't comment but I'd like to extend Jesuspc's answer.
There is a way to achieve that 'mixed' approach, in serverless.yml:
resources:
- ${file(resources/first-cf-resources.yml)}
- ${file(resources/second-cf-resources.yml)}
- Resources:
SomeResource:
Type: ...
In this case files first-cf-resources.yml and second-cf-resources.yml must have the next structure:
Resources:
SomeResourceA:
...
AnotherResourceB:
...
Take note that the resources property has to be an object containing a Resources property, NOT an array of resources like what you wanted in your code snippet.
So, to use external file references, you can do something like...
resources
Resources:
UsersTable: ${file(../resources/base.yml):UsersTable}
FooTable: ${file(../resources/foo.yml):FooTable}
Reference: Reference variables in other files
I have a content directory called foo and I want all files under that directory to have an extra metadata item foovar: default, unless explicitly overridden in the file header. I think I'm supposed to do this with EXTRA_PATH_METADATA, but I can't figure out what incantation it wants.
(for my current use case I'm trying to apply template: sometemplate within this dir, but I'm interested in solving the general case as it would make several related headaches go away)
I think what you're looking for is actually DEFAULT_METADATA. Check out this portion of the documentation:
DEFAULT_METADATA = {}
The default metadata you want to use for all articles and pages.
So, in your case it might look something like this in your config file:
DEFAULT_METADATA = {'foovar': 'default'}
Then to assign your custom template(s), see this portion of the documentation.
This wasn't possible at the time I asked. I've since sent the devs a PR adding support, and it's been merged to master. Presumably it will go out in the next release. It makes EXTRA_PATH_METADATA recursive, so you can apply settings to a subdir like this:
EXTRA_PATH_METADATA = {'dirname/subdir': {'status': 'hidden'}}
Say I want to make a module for say a set of GUI controls, how would I create a module that would load all of the GUI scripts, and should I put those scripts as modules themselves? I was thinking of having a system like this:
module("bgui", package.seeall)
dofile("modules/bgui/control.lua")
dofile("modules/bgui/container.lua")
dofile("modules/bgui/screenmanager.lua")
dofile("modules/bgui/form.lua")
dofile("modules/bgui/button.lua")
dofile("modules/bgui/textbox.lua")
dofile("modules/bgui/label.lua")
Would all the files run then have the variables they set as part of the bgui module?
Aka if in control.lua I had control = {...} would it be defined as bgui.control or should I make the control.lua a module itself, something like module("bgui.control") would that work as I intend?
Sorry if this isn't very clear had to write it in a rush, thanks :)
You are actually asking two questions here:
First, "is this way of loading lots of files on a module ok?"
The answer is - yes. It is kind of an unspoken standard to call that file mymodule/init.lua. Most people have ?/init.lua included on their path, so you can just write require('modules/bgui') and init.lua will be loaded automatically.
This said, you might want to remove some code duplication by using a temp table and a loop:
# modules/bgui/init.lua
local files = {
'control', 'container', 'screenmanager', 'form', 'button', 'textbox', 'label'
}
for _,file in ipairs(files) do dofile("modules/bgui/" .. file .. ".lua") end
Second, "are objects defined on one file available on bgui?".
The answer is also yes, as long as the file defining the variable is "done" (with dofile or require) before the file using the variable.