I'm using Sylius 1.0.0-dev
I created a custom "typed" Resource named manufactured_item.
I need to create a custom backend Grid, displaying my Resource depending of it's type, thus I want to specify a custom repository method.
I also need to create custom actions in main & item sections.
My configuration is the following:
app_production_manufactured_items:
resource: |
alias: app.manufactured_item
section: production
templates: ProductionBundle:Crud
only: ['index']
grid: app_production_manufactured_items
permission: true
vars:
all:
subheader: sylius.ui.manage_your_orders
templates:
form: ProductionBundle:ManufacturedItem:_form.html.twig
index:
icon: cube
type: sylius.resource
I tryed to add something like this, but it does'nt work
# defaults:
# _sylius:
# repository:
# method: myCustomRepositoryMethod
I've read the in the resource the grid (freshly updated) and various thread in SO & Sylius repo, can't find a clue.
Any idea ?
Related
we are in process of shifting to vRA 8.5 from vRA 7.6. We are trying to add dynamic tags to cloud template based on user input and some workflow in backend which decides the placement of machine and network to use.
Currently we are able to place and provide network of our choice by directly using tags in Cloud Template however we want that to happen dynamically on Events such as Compute Reservation & Compute Allocation. Is there any way to this please? I have pasted the code below which we need to change on above Event Subscriptions
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
networkType: existing
constraints:
- tag: site:0005
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
properties:
networkType: existing
constraints:
- tag: infoblox-demo
- tag: SG:5021
So I have a env.yml file which lets me have a different variables for each stage:
provider:
name: aws
environment: ${file(env.yml):${opt:stage}}
I also need to share some output variables to Lambda which are declared like so:
Outputs:
UserPoolId:
Value:
Ref: QNABUserPool
Export:
Name: ${self:provider.stage}-UserPoolId
UserPoolClientId:
Value:
Ref: QNABUserPoolClient
Export:
Name: ${self:provider.stage}-UserPoolClientId
I've seen I can do this by adding this to my provider but this conflicts with my env.yml
environment:
COGNITO_USER_POOL_ID: ${cf:${self:service}-${self:provider.stage}.UserPoolId}
COGNITO_USER_POOL_CLIENT_ID: ${cf:${self:service}-${self:provider.stage}.UserPoolClientId}
I tried putting these into the env.yml but that didn't work:
Trying to request a non exported variable from CloudFormation. Stack name: "XXXX-alpha" Requested variable: "UserPoolId".
I tried using custom instead of environment and it deployed but the Lambda functions no longer had access to the variables.
So how can I mix these two together?
Thank you so much!
You can reference the Output values from your current service using the Fn::ImportValue function.
The serverless system adds sls-[service_name] to the variable but you can find them in the Outputs area of the CloudFormation Stack.
Navigate to CloudFormation --> Stacks --> [select your service] --> Outputs (tab). From there you'll see a column called Exports name.
Use that Exports name and use that for the import.
e.g. you have a WebSocket service and you need the service endpoint. If you look in the tab it will have an export ~ sls-wss-[your_service_name]-[stage]-ServiceEndpointWebsocket. Thus, you can import that into an environment variable:
Environment:
Variables:
ENDPOINT:
Fn::ImportValue: sls-wss-[your_service_name]-${opt:stage}-ServiceEndpointWebsocket
I want to customize the boilerplate code of the new makerbundle crud maker. There is no simple overwriting the templates as it was in SensioGeneratorBundle. I tried to generate a custom MyMakeCrud based on the original code - but i struggle about the injected DoctrineEntityHelper $entityHelper.
Cannot autowire service "App\Maker\MakeMyCrud": argument "$entityHelper" of
method "__construct()" references class "Symfony\Bundle\MakerBundle\Doctri
ne\DoctrineEntityHelper" but no such service exists. You should maybe alias
this class to the existing "maker.doctrine_entity_helper" service.
The existing maker.doctrine_entity_helper is defined private in the maker bundle. How can i get the injection to run?
Could you help me? Has anyone an example for customizing the crud generation? New in sf4.
You have to define a service for it like below:
app.maker.make_crud:
class: App\Maker\MakeCrud
arguments: ['#maker.doctrine_helper']
calls:
- [configureCommand, ['#security.command.user_password_encoder', '#?']]
- [interact, ['#?', '#?', '#security.command.user_password_encoder']]
tags:
- { name: maker.command }
I placed this in config/services.yaml.
App\Maker\MakeCrud is your crud maker class.
Should really place this in a services_dev.yaml file.
Hope this helps.
Many thanks to both of you for this post. I had to customize the MakeCrud command too.
This is the configuration which worked for me for version 5.
app.maker.make_crud:
class: App\Maker\MakeCrudCommand
arguments: ['#maker.doctrine_helper', '#maker.renderer.form_type_renderer']
calls:
- [configureCommand, ['#security.command.user_password_encoder', '#?']]
- [interact, ['#?', '#?', '#security.command.user_password_encoder']]
tags:
- { name: maker.command }
I am trying to find a way to inherit/override environment variables in jenkins jobs defined via jenkins-job-builder (jjb).
Here is one template that does not work:
#!/usr/bin/env jenkins-jobs test
- defaults: &sample_defaults
name: sample_defaults
- job-template:
name: 'sample-{product_version}'
project-type: pipeline
dsl: ''
parameters:
- string:
name: FOO
default: some-foo-value-defined-at-template-level
- string:
name: BAR
default: me-bar
- project:
defaults: sample_defaults
name: sample-{product_version}
parameters:
- string:
name: FOO
value: value-defined-at-project-level
jobs:
- 'sample-{product_version}':
product_version:
- '1.0':
parameters:
- string:
name: FOO
value: value-defined-at-job-level-1
- '2.0':
# this job should have:
# FOO=value-defined-at-project-level
# BAR=me-bar
Please note that it is key to be able to override these parameters at job or project level instead of template.
Requirements
* be able to add as many environment variables like this without having to add one JJB variable for each of them
* user should not be forced to define these at template or job levels
* those var need to endup being exposed as environment variables at runtime for pipelines and freestyle jobs.
* syntax is flexible but a dictionary approach would be highly appreciated, like:
vars:
FOO: xxx
BAR: yyy
The first thing to understand is how JJB priorities where it will pull variables in from.
job-group section definition
project section definition
job-template variable definition
defaults definition
(This is not an exhaustive list but it's covers the features I use)
From this list we can immediately see that if we want to make job-templates have override-able then using JJB defaults configuration is useless as it has the lowest precedence when JJB is deciding where to pull from.
On the other side of the spectrum, job-groups has the highest precedence. Which unfortunately means if you define a variable in a job-group with the intention of of overriding it at the project level then you are out of luck. For this reason I avoid setting variables in job-groups unless I want to enforce a setting for a set of jobs.
Declaring variable defaults
With that out of the way there are 2 ways JJB allows us to define defaults for a parameter in a job-template:
Method 1) Using {var|default}
In this method we can define the default along with the definition of the variable. For example:
- job-template:
name: '{project-name}-verify'
parameters:
- string:
name: BRANCH
default: {branch|master}
However where this method falls apart if you need to use the same JJB variable in more than one place as you will have multiple places to define the default value for the template. For example:
- job-template:
name: '{project-name}-verify'
parameters:
- string:
name: BRANCH
default: {branch|master}
scm:
- git:
refspec: 'refs/heads/{branch|master}'
As you can see we now have 2 places were we are declaring {branch|master} not ideal.
Method 2) Defining the default variable value in the job-template itself
With this method we declare the default value of the variable in the job-template itself just once. I like to section off my job-templates like this:
- job-template:
name: '{project-name}-verify'
#####################
# Variable Defaults #
#####################
branch: master
#####################
# Job Configuration #
#####################
parameters:
- string:
name: BRANCH
default: {branch}
scm:
- git:
refspec: 'refs/heads/{branch}'
In this case there is still 2 branch definitions for the job-template. However we also provide the default value for the {branch} variable at the top of the file. Just once. This will be the value that the job takes on if it is not passed in by a project using the template.
Overriding job-templates variables
When a project now wants to use a job-template I like to use one of 2 methods depending on the situation.
- project:
name: foo
jobs:
- '{project-name}-merge'
- '{project-name}-verify'
branch: master
This is the standard way that most folks use and it will set branch: master for every job-template in the list. However sometimes you may want to provide an alternative value for only 1 job in the list. In this case the more specific declaration takes precendence.
- project:
name: foo
jobs:
- '{project-name}-merge':
branch: production
- '{project-name}-verify'
branch: master
In this case the verify job will get he value "master" but the merge job will instead get the branch value "production".
I want to use puppet to manage some servers. Even after reading dozens of documentation pages, it is not clear to me how to use modules and how to use them with hiera. As first experiment I wanted a user "admin" to be created on one node and found this module -> https://github.com/camptocamp/puppet-accounts
My /etc/puppet/hiera.yaml looks as simple as this
---
:backends:
- yaml
:hierarchy:
- node/%{::fqdn}
- common
:yaml:
:datadir: /etc/puppet/hieradata
My /etc/puppet/hieradata/node/node1.example.com.yaml contains this
---
accounts::users:
admin:
uid: 1010
comment: admin
accounts::ssh_keys:
admin:
comment: ad
type: ssh-rsa
public: AAAAAAAAAAAAAA
This worked after I put this in my /etc/puppet/manifests/site.pp
hiera_include('classes')
class
{
'accounts':
ssh_keys => hiera_hash('accounts::ssh_keys', {}),
users => hiera_hash('accounts::users', {}),
usergroups => hiera_hash('accounts::usergroups', {}),
}
accounts::account
{
'admin':
}
Is this good practice? To me it feels wrong to put that stuff into site.pp since it gets messed up when I later use more modules. But where else to put it? I also don't understand how this separates data from logic, since I have data in both, node1.example.com.yaml and site.pp (admin). Some help would be great..
To understand what hiera is, you should think simply that Hiera is a DATABASE for puppet, a database of Variables/values and nothing more.
For a beginner I would suggest to focus on other parts of the system, like how to create modules! and how to manage your needs (without complexity) and then slowly build the "smart" recipes or the reusable ones...
Your puppet will first sick for a file called sites.pp (usually is on your main $confdir (puppet.conf variable. I am not going to mention environments it is for later.)
e path is /etc/puppet inside that directory, you have a directory manifests. There is the place for your sites.pp
usually a sites.pp structure is:
node default {
include *module*
include *module2*
}
node /server\.fqdn\.local/ {
include *module2*
include *module3*
}
this means that you have a default Node (if the node name doesn't fit any other node, will use the default, otherwise it will use the regex matching of the node FQDN in this case server.fqdn.local.
The modules (module, module2 and module3) are stored inside the $modulespath set on your puppet.conf. In our case i will use the: /etc/puppet/modules
the tree will look like:
/etc/puppet/modules/
/etc/puppet/modules/module/
/etc/puppet/modules/module/manifests/
/etc/puppet/modules/module/manifests/init.pp
/etc/puppet/modules/module2/
/etc/puppet/modules/module2/manifests/
/etc/puppet/modules/module2/manifests/init.pp
/etc/puppet/modules/module3/
/etc/puppet/modules/module3/manifests/
/etc/puppet/modules/module3/manifests/init.pp
About
classes: https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html
generally what i explained but from puppet labs: https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html
Please note that the example from the README
class { 'accounts':
ssh_keys => hiera_hash('accounts::ssh_keys', {}),
users => hiera_hash('accounts::users', {}),
usergroups => hiera_hash('accounts::usergroups', {}),
}
is catering to users of Puppet versions before 3.x which had no automatic parameter lookup. With a recent version, you should just use this manifest:
include accounts
Since the Hiera keys have appropriate names, Puppet will look them up implicitly.
This whole thing still makes no sense to me. Since I have to put
accounts::account
{
'admin':
}
in a manifest file to create that user, what for is hiera useful in this case? It doesn't separate data from logic. I have data in both, the .yaml file (ssh keys, other account data) and in a manifest file (the snippet above). By using hiera I expect to be able to create that user inside /etc/puppet/hieradata/node/node1.example.com.yaml but this is not the case. What is the right way to do this? What for is the example hiera file of this module useful? Wouldn't it be easier create an account the old style way in site.pp?