Dialogflow has a Versions and Environments BETA. I understand that creating a version captures the current state of your agent. I would like to know if this includes training phrases? When I tried to revert to a different version it did not rollback the changes changes to the training phrases
Secondly, if anyone can answer this question - what is the point of creating a version without publishing?
Quoting the docs:
A version is an immutable copy of the current state of your agent, which you can then publish to an environment. When a new version is created, a snapshot of the intents and entities in your current agent is used.
So it should work, but you would also have to publish an environment. Please note that this is currently a beta feature, so it might have some issues.
Personally I am using option to export agent data to zip file through API and version through this data in a separate repository.
Related
I'm using Google Cloud Profiler (located at https://console.cloud.google.com/profiler) and would like to know how my profiling data changes across different builds of my application.
One way to do that would be to check the range of dates during which a particular commit was running on production, but that's time consuming because I have to:
Get the start date/time of release, determine the date/time of the next release
Set those dates manually in the profiler interface from the link above
That's really not terrible, but it'd be great to be able to set BUILD_ID environment variable like I can in Cloud Build and then be able to access that from the UI. Is something like this possible? Or is my approach the best way to do this at the moment?
Comparing across service versions would likely be a simpler and more precise way to do this (as opposed to using the time interval to select for profiles). To compare across service versions, it is necessary that the profiling agents set the service version.
The service version can be specified in the configuration passed to the agent (for the Go, Python, or Node.js agent) or via the -cprof_service_version flag (for the Java agent). If one is setting the service version using the configuration passed to the agent (applicable for the Go, Python, and Node.js agents), it may be convenient to use a flag or command line argument to set the service version so that the source code won't need to updated with each new version.
If one is running on Knative or App Engine standard, the service version should be auto-populated. These environments set the K_REVISION and GAE_VERSION environment variables (respectively), and the profiling agents (for all supported languages) use these environment variables to populate the service version. If one is running in another environment and modifying the source code is inconvenient or infeasible, one can set either the K_REVISION or GAE_VERSION environment variable in the environment running the application with the agent enabled to specify the service version.
My understanding is that the BUILD_ID is available at build time, but not at run time, so I don't know that it's possible for agents to use that directly.
(Disclosure: I work on Cloud Profiler at Google)
You can set the service version for this purpose. Please refer to the agent documentation for how to set it for supported languages.
For example, this shows using ServiceVersion for Go services.
Is there a way to setup up a build's priority in a yaml based pipeline? There seem to be references to build priority in the Azure DevOps API, but nothing in how to do this via yaml. I thought there might be some docs in the Triggers section, but no.
We need this because we have some fast building NuGet packages, but these get starved via slow-build pipelines making turnaround time for packages painful.
The closest thing I could come up with to working around this is via agent demands in the yaml
demands:
- Agent.ComputerName = XYZ
to separate build pipelines, but this is a bit of a hack and doesn't use agents efficiently.
A way to set this in UI would be acceptable, but I couldn't seem to find anything.
Recently Azure DevOps introduced the ability to manually specify a build/release runs next.
This manifests as a Run next button. (image source).
So while you can't say "this pipeline always takes priority" yet, you can manually force a specific run to the front of the queue.
If you need a specific pipeline to always take priority, then you likely want to setup a separate agent pool just for those pipelines, or use demands as Leo Liu mentioned.
Setting build priority in yaml or UI
I'm afraid this feature is not yet supported in Azure DevOps at this moment.
There is a popular user voice about it, you can upvote it and check the feedback from that ticket.
Currently as a workaround, just like what you did, set the demands in build definitions to force building with the specific agents.
Hope this helps.
Problem :
Is it possible to change any information pertaining to the stage-names in BPMN work-flow for previous versions or do we need to deploy a new version for such minor changes?
Not really sure, what you mean by "stage names", but every change to the bpmn xml has to go through deployment to be available on the engine.
You don not have to manually create a new version, camunda will just create a new revision based on same key and version for you.
I have a tool which requires boto3's direct connect functionality. However I cannot tell from which version onwards boto3 includes this functionality.
Is there any way to obtain the older version of the docs to see at which point direct connects were added?
At this point in time the latest is 1.4.4.
boto3 development is an open source initiative. So you can always checkout botocre development repository for the release notes, or ask question there.
changelog.rst will show a brief list of changes.
Then use following command to switch to specify tag version and look for the date of commit.
git checkout tags/<version_name>
We are currently experimenting with Hyperledger's chaincode and wondering how we can gain access to the state held by an old version of a chaincode.
It is my understanding that the state created by a chaincode cannot be accessed by other chaincodes except through a query transaction. But, what happens when there is need to fix bugs/issues by releasing an updated version. How can we have full access to the state in the old chaincode?
Since direct access to the old chaincode state is not possible, does it mean we will have to build a mechanism within the chaincodes that allows for its state to be downloaded/copied/forked?
Querying old data from old chaincodes would be a nightmare when data is fragmented across many versions of a chaincode.
I don't have any documentation to support this now, but Fabric v1.0 seems to have a variant of this feature - with a new switch called "upgrade".
Have not tried it myself. So do not know whether the state can be made available across the different versions of the same chaincode. And the reason for the broken link is the difference in the Chaincode Id between two versions of the same chaincode.
Take a look at this YouTube video, Upgrade Chaincode. (Please note that this video uses the development mode, so Chaincode can be referred with the given name like mycc)
Also take a look at the fabric feature enhancement plan here for a mention of this featureFabric next, presentation