our project "XY" is certified and deployed in production. We are migrating our production from bare metal to cloud platform. In the process we are changing DNS and domain. The only changes we are trying to achieve are update fulfillment and linking endpoints for this project.
According to: https://developers.google.com/assistant/smarthome/develop/launching#modify-action
We must go through 3 stages:
Resubmit your test suite results.
Fill out a new certification request form.
Resubmit your Action for review.
The first phase is not accomplishable:
In order to run the test suite:
A) Enabled device testing for current draft. (Success)
B) Link action to your google account using the same account you used to sign in to the actions console. (failed)
Why does the "B" fail ?
Enabling current draft for testing do not reflect changes in the fulfillment and linking endpoints.
During the linking process in the Google Home app there is no option to select draft under the [test] prefixed section. I can only see linking for the deployed version which is already certified but has old endpoints to fulfillment and linking. The test suite has no relevance against the deployed version. I want to test against the current draft.
I've come across the same problem:
Testing the Google Smart Home Action
What can I do for resubmit test suite results ?
Thanks for pointing this out, we are working to improve this process.
For testing of your new configuration, I'll bring over part of the answer from the question you linked:
Once your Action is deployed to production, the project will no longer reflect console changes to the test agent until those changes are submitted and reviewed. The recommended way to work around this constraint is to create a second project in the Actions console that you can use to test/validate your change.
For deploying production, I would recommend resubmitting your new Action version for review without using the test suite. During review, the certification team will reach out to you and work with you on the fact that this is an update to an existing Action.
Related
We have a heroku review app pipeline configured with github integration.
Currently, every time after a new app is created, we have to go in and manually disable automatic deploys in the UI here:
I was looking around for one of the following options to remove this manual step:
call an api to disable auto-deploy on a review app
change a pipeline level setting that determines the default value of auto-deploy for new review apps that get created
but so far I haven't been able to find anything.
Any suggestions for how this might be achieved would be much appreciated.
i am interested in building a github app. reading through github Setting up your development environment to create a GitHub App documentation it explains that a github app is based on a http server which will handle webhooks.
yet, on every github app i installed, the app\installation did not require anything that involves hosting and/or creation of http server in order to deploy the app to my github accout.
for such github apps, which are installed directly through the github marketplace (you can take probot stale and rennovate as examples for such apps)
where do these application run? (e.g.; does github deploys the app on a dedicate (virtual) server?).
what are the resources limitations for such apps (amount of memory, cpu, etc.?)
how can the github app logs be accessed by the github account owner who installed such app?
links for reference and an answer will be great.
GitHub App is just another app that you create. GitHub apps are treated as first-class citizens when it comes to integrating with GitHub. One can use Nodejs , Ruby, etc to build the App. Once the app is ready it can be hosted on a Server just like any other server hosted apps. You register your app on GitHub by providing relevant details.
So, coming to your questions.
The Apps can run on any hosting service of your choice. It can be a Windows Server, Heroku, etc.
I believe it is only limited by the resource of your server or the hosting service provider that you chose. However you might be ineterset in erading more about the Rate Limit More on Rate limits here.
GitHub app logs are something which only the developer will be able to see. To the end user ,i.e. the repo owner who installed the GitHUb app on his repos, all that will be available are the checks , statuses and any other details that the developer of app decided to display.
A very handy guide on Deployment and other details : Probot Documentation. This documentation is great if you are planning to use the probot framework for developing your github apps, but most of the instructions still stand true in case you decide to pick up a different tech stack.
The most important thing to realise about a (so-called?) Github App is that the App itself does not run anywhere - or at least that is what I would argue. Basically Github Apps are two linked mechanisms, both a bit of infrastructure. The first of these mechanisms is access control, essentially replacing use of user PATs - you can give relatively fine grained access to repos that the App is installed in, rather than just giving access to all repos the user can access. The second mechanism is that of webhooks - generating events as requested.
What Github Apps do not directly provide is the bit between this - handling the webhooks and generating API calls using the App for access. Basically you are on your own and need to do it yourself. The plus, #asif-kamran-malick mentioned, is that you have freedom to implement it how you see fit.
One alternative possibility is that the App itself, rather than setting to handle ongoing Webhooks, runs on installation and looks to add Actions into the repo. Never done it, but some of the github examples seem to work this way. Of course, Actions are run within Github environments and are potentially subject to resource limits. Apart from this though, Actions are a completely separate "beast" and should not be confused.
I have a pipeline built where, simplified, it deploys a chatbot to a QA Bot Service and then, with a pre-deployment approval, to a PROD Bot Service. Normally it works fine. However, if I do not approve the release, my PROD Bot Service gets wiped (the project files are gone). I tried moving the approval to a post-deployment approval on the QA Bot Deployment, and I have the same exact issue. So my question is, why are my PROD Bot Service files being affected if that step is never being run? I need to be able to cancel the release without impacting the existing production code!
Edit: Updated with additional context. I have determined the issue is happening at provision Azure resources step. Somehow that is causing the code to clear out, before I get to ANY bot service deployment steps. Updated title as well to match issue.
I figured it out. When you set the app service configuration settings, everything is cleared out except the settings you put in (annoying, but that's a whole other issue...). My issue was that I didn't have the WEBSITE_RUN_FROM_PACKAGE = 1 setting in the ARM template. Apparently, if you do not set this value, your bot code (if previously deployed from package via DevOps) will be cleared out. I never noticed this because if you finish the release, this value will be set by your Bot Service Deployment action, and we hadn't cancelled any releases (or had immediately redeployed).
In short, WEBSITE_RUN_FROM_PACKAGE = 1 is required in the ARM template if you are setting any other app settings. Otherwise, bot code previously deployed by DevOps package will be cleared as soon as the provisioning step is completed. Adding this value fixed the issue.
I am trying to integrate Percy.io, a visual regression testing tool with Github status check.
I have signed up for free account with Percy and paid Github version.
I wanted to setup status check with Percy with each pull request as below suggested at percy doc on status check
I have integrated Percy in Github
Added rules in Github
but still don't see check on pull request.
Added same project in percy.io too
Any Idea what I am missing over here?
It's hard to be specific without knowing more about your application, however one piece that seems to be missing from your setup is a CI/CD configuration.
Basically, you need a Continuous Integration service (such as Travis, Jenkins, CircleCI or others to trigger a build for your project so that percy can capture snapshots. Did you configure one?
See the documentation here.
Here an example configuration for one of my projects. Note that how you set this up may differ if you use a different set of tools than what's in the article.
When I open my Instant Games app I get Your instant game doesn't have a production version error.
How can I specify such production version without Web Hosting (thus uploading a .zip archive)?
Instant Games are always hosted by Facebook.
It sounds like you simply missed to perform the necessary steps as they are outlined under https://developers.facebook.com/docs/games/instant-games/test-publish-share#testing, specifically the “Productionize the Build” step:
To test the upload in a production environment, the build must first be staged for production. Click the "★" button to push the build to production.