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.
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.
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.
I've installed the Google Cloud Build app from Github Marketplace, and enabled it on several repositories, only to discover that enabling access for those repositories automatically starts running the Google Cloud Build "check" after every PR or push to a PR. Since some of those repositories are not actually ready for Google Cloud build, I needed to turn off the checks... I used the URL mentioned in the docs to get to the page where you can select which repositories should be connected to your GCP project, and unchecked a bunch of them... this disconnected them from the project, but, surprisingly, did not disable the Github checks! So now, there are Github checks on several repositories that just result in an error because they're not connected to any projects in Cloud Build.
Surely, it is not an uncommon use case to need a way to "disable Checks" on a per-repository basis - is there any way to do that?
(If not, consider it a requested feature if there are any Google Engineers reading!) ;)
I did talk to chat support, and the only way we could figure out to remove the checks would be to uninstall Google Cloud Build completely from the entire organization, which I don't want to do because we do have some setup that I want to keep, and I don't know how much of that configuration would have to be redone if I uninstalled it completely.
Here is a screenshot of the broken check that I can't disable:
I think there are 2 steps to disable CloudBuild,
1. Disable on CloudBuild itself. For some time I kept seeing 2 builds per push made, but disabling a trigger on CloudBuild helped fix that.
2. On Github, you can configure the Cloudbuild app to monitor a specific repo on the organization level setting.
3. If you feel a lot adventurous though and it's not solved, on the project level setting, you could delete the Webhooks integration for cloudbuild, as that's what Github notifies of each build.
It can be found within GH App installations:
https://console.cloud.google.com/gcb-github-registration
Select the GH account used for your link between Cloud Build and GH, then the GCP project you want to edit.
Here connected repositories can be edited, and in the second step (Trigger settings), the "Default GitHub Checks" can be disabled.
You can also goto settings of your repository and click installations inside settings.
And then remove Google cloud build from Installed apps and authorized github apps.
Cloud Build Triggers are still in beta, and have gone through several updates since this question was posted, but it now appears that the "Github Default Checks" are no longer hidden from management. They are now explicitly offered (but not automatically created) when connecting a repo, and you can finally view and disable (or delete) individual "Github Default Checks" on the trigger management page: https://console.cloud.google.com/cloud-build/triggers
I'll leave this as unanswered, because I'm uncertain this is how it is working for everyone, or that this answer will remain true, but if it works for you, feel free to vote up the answer!
To link GCP Project to the Github repository, create a trigger by clicking on resolve link, besides Action Required and then disable the same. For me this procedure worked out.
I've used Beanstalk and Tower in the past for version control, however, is there a way to connect Shopify to GitHub?
Ideally, I'd like to have a copy of my Shopify theme on my desktop to work on, then when I'm ready to push the changes, I'll use the GitHub Desktop app to push to Shopify.
How do I go about connecting Shopify and GitHub together?
Cheers
In order to preview your local changes on a Shopify theme you need to push them to the Shopify server and test them on a development store or as an unpublished theme on a live store.
Accordingly, I would recommend using a command line tool like Shopify's slate (https://github.com/Shopify/slate). This will allow you to watch for changes in your local files and push them to your Shopify store. I wrote a post here on setting up a new theme for local dev with slate http://www.codeshopify.com/blog_posts/local-shopify-development-with-slate
In terms of git / github integration you can use this for version control the same way you would any other site.
When it comes time to put your Shopify site live you can simply publish the theme and make sure you have removed the storefront password.
I think that you need a Premium Shopify account , but anyways if you have 1 I recommend you to use this : https://zapier.com/zapbook/github/shopify/ !
It explains you step by step on how to do it!