The below xaml loosely describes a number of steps that can be re-arranged into many different configurations, and nested levels.
---
sequence:
- manual:
desc: unpack baloons
- electric:
desc: inflate each balloon
- parallel:
- manual:
desc: seal a balloon
- manual:
desc: sign a balloon
- sequence:
- manual:
desc: step 1
- manual:
desc: step 2
There are a number of *resolvers and *converters, however a good advice on which one to use when would be very helpful. How to register custom type factories and in what places?
Related
I want to trigger an Argo workflow to start running at a specific time. I am currently using a workflowTemplate and the rest API to submit a workflow with this template. Is there a way to tell Argo to start the workflow at a specific time.
I am aware of the existence of cron-workflow and cron-workflow-template. But I am not able to figure out how to use either workflow or cron-workflow to achieve what I want.
To have any scheduling, do I must use cron-workflow? Or is there a way to trigger a regular workflow at a delay by passing the schedule-time in submitOptions or in some other way through the rest API?
If I must use cron workflow, what should I set the schedule value at? I don't want it to run automatically or periodically, but only when I want and at a specific time. Is there a way achieve that using cronWorkflowTemplate and the rest API?
I will appreciate any help/pointers.
Likely not the answer you're looking for, but if you are able to alter your WorkflowTemplate, you can make the first step be an immediate suspend step, with a value that is provided as an input (by you, when deciding you want to submit the workflow, just not now). For instance, your workflow may look something like this:
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: my-workflow-template
spec:
entrypoint: my-wf
arguments:
parameters:
- name: wait-time-sec
value: "0" # override me
templates:
- name: my-wf
inputs:
parameters:
- name: wait-time-sec
steps:
- - name: wait
template: wait-template
arguments:
parameters:
- name: wait-time-sec
value: "{{inputs.parameters.wait-time-sec}}"
- - name: rest of original workflow steps...
- name: wait-template
inputs:
parameters:
- name: wait-time-sec
suspend:
duration: "{{inputs.parameters.wait-time-sec}}"
...
When you want to submit it, just pass in the parameter wait-time-sec. Granted, if you would rather have a specific time, you would either have to calculate how many seconds that would be before submitting, or write a simple script before the wait step to do that calculation for you, taking in an input of a datetime and outputting seconds for the wait step to use.
Can azure devops pipeline yaml drive picklist values from a file so to avoid hardcoded values in yaml ? Even better allow an api call to dynamically populate a list
Naturally we can roll our own synthesis of pipeline yaml code short of that would be nice if it allowed an include snippets file ability ... one means would be to run a pipeline to generate a pipeline to get run
azure pipeline bad technique today requires a hardcode
parameters:
- name: some_parm
type: string
default: fav_value
values:
- val01
- val02
- val03
what is needed ... populate list dynamically or at a minimum from a file
parameters:
- name: some_parm
type: string
default: fav_value
values:
${{ some_file_or_api_lookup }}
Possibly this yaml preprocessor could work https://github.com/birchb1024/goyamp ... dunno yet
UPDATE 20220906 so far no solution found suggestions welcome
I am using snips-nlu to create a "simple" chatbot for managing certain tasks. But I seem to lack the understanding of how (if possible) to add new intents on the go during runtime.
The issue I face is let's say I have the following in my yaml file:
type: intent
name: questionAboutFood
slots:
- name: foodType
entity: foodType
utterances:
- what color is a [foodType]
- where can I buy a [foodType]
---
type: entity
name: foodType
automatically_extensible: yes
values:
- banana
- apple
- orange
from this file I can fit it to my snips-nlu engine.
But How do I during runtime append more foodTypes?
CODE:
from snips_nlu import SnipsNLUEngine
from snips_nlu.default_configs import CONFIG_EN
import io
import json
seed = 42
engine = SnipsNLUEngine(config=CONFIG_EN, random_state=seed)
with io.open("dataset.json") as f:
dataset = json.load(f)
engine.fit(dataset)
parsing = self.engine.parse("what color is the apple?")
I can see two workarounds:
Re-train
One way to do that consists in dynamically re-training the engine with the dataset updated with the additional entity values. This may be a reasonable solution if your dataset is not too big, as the training will be quite fast.
Improve the dataset
The other solution consists in providing many more formulations of your intent in the yaml file, so that the resulting engine will be able to extract unseen entity values.
In your case, you only provided two formulations in which the entity is the last token. Besides, the entity values you provided are only unigrams. For these reasons, it is likely that the NLU engine will not be able to capture entities when they span several tokens and/or when they are located in the middle of the sentence.
Here is a slightly better dataset which will already generalize much better:
type: intent
name: questionAboutFood
slots:
- name: foodType
entity: foodType
utterances:
- what color is a [foodType]
- what is the color of an [foodType] in general
- how much does an [foodType] cost
- can you describe a [foodType] for me please
- in which country is [foodType] generally found
- where can I buy a [foodType]
- how big are [foodType] in average
---
type: entity
name: foodType
automatically_extensible: yes
values:
- banana
- apple
- orange
- red meat
- black eyed pea
- brussels sprouts
So basically i've create an installer with inno setup, it works wonders and all of that. The issue is the fact that i've developed the following [Components]
Name: "LoremIpsum"; Description: "LoremIpsum"; Types: Server User; Flags: fixed
Name: "Java"; Description: "Java Runtime Enviroment"; Types: Server User; Flags: fixed
Name: "banco"; Description: "Database"; Types: Server
Name: "banco\padrao"; Description: "Standard Database"; Flags: exclusive; Types: Server
Name: "banco\manual"; Description: "Manual Database"; Flags: exclusive; Types: Server
Name: "banco\fullrestore"; Description: "Full Restore Database"; Flags: exclusive; Types: Server
Name: "banco\backupdata"; Description: "Database with Backup Data"; Flags: exclusive; Types: Server
Then, in the installer wizard when you're in the part where you choose the type of installation, there are two types, the basic one which doesn't include the "banco" part, and the complete one which is the one that i provided the code.
If you choose the complete one it looks exactly like the full one except for the name of the type of installation. Of course if you're in the basic one and mark one of the 'banco' options you'll be automatically transfered to the full installation, but i wan't it so that if you choose the full option one of the 'banco' options should be marked by defautl, i figured that it should be the father 'banco' and son 'banco/padrao' but i can't figure out how to do it.
I've already looked in the documentation looking for some sort of "Deafult" flag, which i couldn't find. I assume there should be a way to do this built in the app, i'd rather not have to do the changes with actual code since i'm not really good at pascal which is needed for it, but i wouldn't mind if the solution involved it. Mostly what i wan't is some sort of "Default" flag to appoint into one of the exclusive options. Does anyone know of such a function?
The following is the [Type] section
Name: "User"; Description: "Basic install"; Flags:
Name: "Server"; Description: "Full install" ; Flags: iscustom
#MartinPrikryl comments got me thinking, and with some time i realised that he was right, just that his solution didn't do what i want. The problem i had as a design one, i wanted thing to look more "pretty" for the end user. I then had a breaktroguh, i realised that i didn't need 2 types of instalations, just one which is custom, then i did just that.
In the end the [Types] was just
Name: "User"; Description: "Basic install"; Flags: iscustom
and that was it, the installer now looks like i want it to, not what i wanted originally but i think it's better than what i had in mind. I also removed the types from the old "server" install leaving them typeless, and removed the server type also from the fixed ones. In the end it worked out allright. Special thanks to Martin since i wouldn't have tought about it without his input.
I'm using swagger-node for REST APIs and I've found an absurd issue here.
Here's my one of GET requests:
GET: /students/{id}/{name}
(id is number)
And now I wrote another request:
GET: /students/routeInfo/{id}
But the 2nd request me following error:
Expected type is number, found type string. Which clearly means 2nd request is trying to "mask" 1st request. Which I think shouldn't be.
Am I doing something wrong or is there any other way to handle this?
In your path definitions, changeChange your 'parameters' type: number for type: string
Your path will look like this:
/students/routeInfo/{id}:
x-swagger-router-controller: yourStudentController
get:
tags:
- Student
description: description
operationId: yourOperation
parameters:
- name: id
in: path
description: description id of routeInfo
required: true
type: string
See more at https://swagger.io/docs/specification/paths-and-operations/
The exact same situation is described in the OpenAPI specification v3.0 document: section Path Templating Matching, 3rd example. It is called ambiguous matching, and "... it's up to the tooling to decide which path to use." The tool, of course, being swagger-node.
It is weird though, isn't it!