I have read the official article and it says that dialogflow automatically saves a snapshot of the agent when we release the action into a particular channel like Alpha , Beta or Production.
I have submitted my action for Production and it is under review.
If I make any changes to my action now on the inline editor of dialogflow , they won't be reflected on the
released version would they ?
I am unsure due to the fact that it doesn't say deployed to any channel but says it's under review. Do I have to wait till it's in production ? There is no way to confirm that version control is in place.
If you make changes to either your webhook fulfillment or to the code in the Inline Editor, it goes into effect immediately. There is no version control at all for fulfillment.
At the same time, it means that if you make a change to fulfillment, you do not need to have it re-reviewed before it goes live.
The Alpha, Beta, and Production channels refer to the Intents, phrases, etc.
While, in theory, you can create a different environment for Alpha, Beta, and Production and in each environment use a different URL for the webhook, this definitely won't work if you're using the Inline Editor.
The best solution is to create a completely separate project and do your development and testing in that project.
Related
I am using Pull Request Manager Hub from the marketplace for our azure dev ops projects/repos. id like something that has a cleaner UI. It seems too busy and like everything is a button and some of the icons don't show up completely. I don't want to complain too much but is anyone using something else that they like more? My main requirement is that I should be able to see all pull requests across repositories in the same project.
I’m the creator of Pull Request Manager Hub and new improvements (better UI, lots of new features) have been released to address some of the main complains. Also, feel free to open issues in the GitHub repo where we try to fix as soon as possible.
Thanks ;-)
My main requirement is that I should be able to see all pull requests
across repositories in the same project.
For this demand , you can use Pull Request Search extension. This extension allows pull requests to be filtered by status, creator, reviewer, title, start date, end date, and repository. You can specify different repos in the same project in the Repo drop-down list.
Another extension Pull Request Dashboard can also view pull requests across all repositories. But it has a flaw, you can only see the pull requests with active status.
https://marketplace.visualstudio.com/items?itemName=mimeo-vs-marketplace.mimeo-active-pull-requests has a plugin called 'All Active Pull Requests' (among others) is the best I have found so far.
I'm working on a action on google project, I release the alpha version then the beta version.
But I need to do some changes before to deploy in production.
So my question is:
Before deploying in production, Is there a process review again ?
Yes,
Whenever you are submitting your action to production, there will be review. No matter what changes you have done, what amount of data you have changed.
We upgraded our self-hosted gitlab-ce to the latest 11.11 which brings in multiple reviewer merge request approval feature. Although this needs to be explicitly enabled via gitlab-rails console.
On the machine running our gitlab instance, I ran gitlab-rails console and got to a ruby console where I put in Feature.enable(:approval_rules) and hit Enter but I get:
>> Feature.enable(:approval_rules)
Nothing known about Feature.enable(
I do not have much experience with ruby so am not sure what am doing wrong. I searched on the web but I found documentation on how to develop with Ruby's "feature flags" but not how to enable them as a end user of the application.
You can do it via the GitLab api.
POST to https://gitlab.myhost.com/api/v4/features/approval_rules with the payload
{
"value": true
}
https://docs.gitlab.com/ee/api/features.html
Additionally, I found that the new approval rules workflow was automatically enabled upon upgrading from 11.9 to 11.10, though my experience may be different. If you perform a GET to that API endpoint, you will be able to see its current status.
If it is already enabled, perhaps you may be mistaking the new approval rules implementation with the EE feature Multiple Approval Rules. I only mention due to the -ce tag in your question.
With GitLab 13.5 (October 2020), actual feature flags are available for all:
Feature Flags made available in all tiers
In GitLab 11.4, we introduced Feature Flags.
In GitLab 12.2, we introduced percent rollout and user ID Feature Flag strategies.
In GitLab 13.1, we introduced Feature Flag user lists and support for multiple Feature Flag strategies per environment.
Earlier this year, we committed to moving 18 features to our open source Core product and took the first step in delivering on this promise by making Feature Flags available in Starter in the last release.
Now we’ve officially finished moving Feature Flags to our Core offering. We’re excited about making these features available to more of the GitLab community and seeing the positive impact it’ll have on your development workflow.
See Documentation and Issue.
That includes, still with GitLab 13.5 (October 2020):
Feature Flags flexible rollout strategy
When you use the percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy.
We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.
See Documentation and Issue.
The feature flag API is more about creation/update/deletion.
You will have to use a feature flag strategy in order to enable/disable a feature flag.
Feature.disable(:feature_flags_new_version)
Feature.enable(:feature_flags_new_version)
See also GitLab 13.6 (November 2020)
Fire Webhook on Feature Flag change
As a developer, you can use GitLab’s webhook features for various events, such as MR events, pipeline events, job events, and deployment events. In this release, you can now use webhook events when a feature flag is toggled either on or off. This addition streamlines the process to update your CI/CD pipelines, receive Slack notifications for events, and more. A huge thanks to Sashi for a great community contribution!
See Documentation and Issue.
This morning when I logged into GitLab I noticed this "Next" flag on the top bar:
It appears whether I am logged in or not. What does "Next" indicate?
A Google search turns up nothing. It doesn't appear in any GitLab screen shots I am able to find either.
This is the canary version of Gitlab you are being served, you can find out more here: https://about.gitlab.com/handbook/engineering/#canary-testing
You can swap the version of Gitlab you see here: https://next.gitlab.com/?nav_source=navbar
The reasoning behind providing the Canary versions to users either at random or by those who have opt-ed in:
GitLab makes use of a 'Canary' stage. Production Canary is a series of
servers running GitLab code in production environment. The Canary
stage contains code functional elements like web, container registry
and git servers while sharing data elements such as sidekiq, database,
and file storage with production. This allows UX code and most
application logic code to be consumed by smaller subset of users under
real world scenarios before being made available to all users on
GitLab.com.
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.