issue_comments

This looks like the bug to me:

https://github.com/dogsheep/twitter-to-sqlite/blob/197e69cec40052c423a5ed071feb5f7cccea41b9/twitter_to_sqlite/cli.py#L239-L241

type=str, default=False

Weird, added debug code and got this: {'screen_name': 'simonw', 'count': 200, 'since_id': 'False', 'tweet_mode': 'extended'} - so maybe it's a twitter-to-sqlite bug where somehow the string False is being passed somewhere.

https://developer.twitter.com/en/docs/twitter-api/v1/tweets/timelines/api-reference/get-statuses-user_timeline says the API has been replaced by the new v2 one, but it should still work - and the since_id parameter is still documented on that page.

I'm getting this too. Looking into it now.

I was worried about if it's possible to allow access to /fixtures but deny access to /fixtures?sql=...

From various answers on Stack Overflow it looks like this should handle that:

User-agent: * Disallow: /fixtures? I could use this for tables too - it may well be OK to access table index pages while still avoiding pagination, facets etc. I think this should block both query strings and row pages while allowing the table page itself: User-agent: * Disallow: /fixtures/searchable? Disallow: /fixtures/searchable/* Could even accompany that with a sitemap.xml that explicitly lists all of the tables - which would mean adding sitemaps to Datasette core too.

Actually it looks like you can send a sitemap.xml to Google using an unauthenticated GET request to:

https://www.google.com/ping?sitemap=FULL_URL_OF_SITEMAP

According to https://developers.google.com/search/docs/advanced/sitemaps/build-sitemap

Bing's equivalent is: https://www.bing.com/webmasters/help/Sitemaps-3b5cf6ed

http://www.bing.com/ping?sitemap=FULL_URL_OF_SITEMAP

https://docs.datasette.io/en/latest/internals.html#databases

I deployed a demo to https://datasette-latest-query-info-j7hipcg4aq-uc.a.run.app using the mechanism from #1442.

e.g. demo here: https://datasette-latest-query-info-j7hipcg4aq-uc.a.run.app/fixtures?sql=select+*+from+searchable

https://github.com/ahmetb/cloud-run-faq#how-do-i-continuously-deploy-to-cloud-run suggests the following:

• roles/run.admin to deploy applications
• roles/iam.serviceAccountUser on the service account that your app will use

It also links to https://cloud.google.com/run/docs/reference/iam/roles

I would love to know this too! I always find figuring out minimal permissions to be really difficult.

That successfully deployed to https://datasette-latest-deploy-this-branch-j7hipcg4aq-uc.a.run.app/ even though the tests failed.

I'm going to only run the tests if it's a push to main - that way I can ship demo branches really quickly, even if they don't yet have passing tests.

Would this allow anyone to push a PR to this repo that would result in their code being deployed against my Cloud Run account? I'm reasonably confident that it would not, since the secrets would not be visible to their PR branch.

If I get this working I should document it on https://docs.datasette.io/en/stable/contributing.html

I think the neatest way to implement this would be for the on -> push -> branches list to be the list of branches that should be deployed in this way. The rest of the code can react to that.

Maybe as simple as teaching https://github.com/simonw/datasette/blob/main/.github/workflows/deploy-latest.yml to run on pushes to ALL branches:

https://github.com/simonw/datasette/blob/adb5b70de5cec3c3dd37184defe606a082c232cf/.github/workflows/deploy-latest.yml#L3-L6

And then quit early if the branch is not in some allow-list.

If it IS in the allow-list, use the name of the branch to dynamically construct the name of the Cloud Run service here: https://github.com/simonw/datasette/blob/adb5b70de5cec3c3dd37184defe606a082c232cf/.github/workflows/deploy-latest.yml#L60

Need to skip the documentation build and deployment stuff for other branches though.