Broken: Get repository stats

[dholbach]

operating in /github/workspace/03-22-2307-A611/fluxcd/flagger
fetch.py for fluxcd/flagger
+ python //fetch.py fluxcd/flagger --snapshot-directory=newsnapshots --fork-ts-outpath=forks-raw.csv --stargazer-ts-outpath=stars-raw.csv
230322-23:07:59.183 INFO:MainThread: processed args: {
  "repo": "fluxcd/flagger",
  "snapshot_directory": "newsnapshots",
  "fork_ts_outpath": "forks-raw.csv",
  "stargazer_ts_outpath": "stars-raw.csv"
}
230322-23:07:59.183 INFO:MainThread: output directory already exists: newsnapshots
230322-23:07:59.439 INFO:MainThread: Working with repository `Repository(full_name="fluxcd/flagger")`
230322-23:07:59.575 INFO:MainThread: Request quota limit: RateLimit(core=Rate(reset=2023-03-23 00:06:53, remaining=997, limit=1000))
230322-23:07:59.575 INFO:MainThread: fetch top referrers
230322-23:07:59.697 ERROR:MainThread: this appears to be a permanent error, as in "access denied -- do not retry": 403 {"message": "Resource not accessible by integration", "documentation_url": "https://docs.github.com/rest/metrics/traffic#get-top-referral-sources"}
+ FETCH_ECODE=1
+ set +x
error: fetch.py returned with code 1 -- exit.

[dholbach]

@kingdonb Do we need one more fix similar to #20?

[kingdonb]

Yes, I can take a look at it today 👍

[kingdonb]

https://github.com/jgehrcke/github-repo-stats/wiki/Tutorial#step-1-create-personal-access-token-and-store-it-as-repository-secret

I'm following through on this now, it looks as though we need a GITHUB_TOKEN with repo scope in order to use this.

Has it always been so? That seems excessive, from the description of repo scope in the GitHub Actions docs:

repo | Grants full access to public and private repositories including read and write access to code, commit statuses, repository invitations, collaborators, deployment statuses, and repository webhooks. Note: In addition to repository related resources, the repo scope also grants access to manage organization-owned resources including projects, invitations, team memberships and webhooks. This scope also grants the ability to manage projects owned by users.

We need all that just to read the stats from the repo? Holy hell

Why are we doing this?

https://github.com/jgehrcke/github-repo-stats#github-repo-stats
A GitHub Action (in Marketplace) built to overcome the isaacs/github#399 of GitHub's built-in traffic statistics.

Data that you don't persist today will be gone in two weeks from now.

High-level method description:

This GitHub Action runs once per day. Each run yields a snapshot of repository traffic statistics (influenced by the past 14 days). Snapshots are persisted via git.
Each run performs data analysis on all individual snapshots and generates a report from the aggregate — covering an arbitrarily long time frame.
Looking for a quick start? Follow the simple tutorial in the Wiki.

Can anyone see if we have really provisioned a secret here with repo scope, and maybe it has expired? The error 403 indicates that our access being denied is related to an authentication failure, IMHO.

[kingdonb]

I'm assuming that we did have one, probably it was created with the permission of the core maintainers, with an expiry date. I'm happy to design a process that can keep this token refreshed, but as it is repo scope maybe the decision is better that we just manage this by hand, at least for now. I do not have access to repo settings or secrets on the fluxcd/stats repo, so I can't check on the secret or replace it.

I can copy all this to my own fork and test with a different repo, (just so we have someone that's fully aware of what this repo scope token does and having tested in a scope other than the production setting) but if it's just an expired token, then it will just need to be replaced, and someone else aware that we are doing this I guess.

[kingdonb]

It seems like we could automate this, updating the github secret with repo scope.

We could run a periodic workflow (hourly? every 4h/12h?) on the stats repo, where we'll store a Github App private key as a secret, that has permission to create GITHUB_TOKEN with repo scope for the fluxcd/flux2 and fluxcd/flagger repos. That job will store the new GITHUB_TOKEN – or maybe there is a way to handle this without managing secrets, and only using ambient / delegated credentials. I'll admit, I'm looking for an excuse to use the tf-controller here, (I will probably do it both ways, but only one will go into the permanent situation for fluxcd/stats.)

I will work out on my own personal repos how to do a cross-repo delegation of "write secrets" permission for GitHub Actions, so the fluxcd/flux2 . I am pretty sure we don't need Kubernetes or tf-controller in the workflow to accomplish this (it could just run the github-app-secret app and terraform in an hourly job, with no Kubernetes and just using terraform CLI.)

I was looking for an excuse to use tf-controller, but if there's no permanent Flux cluster I can run this workflow on, it might be better to keep it fully GHA. Then again, we could be spinning up a k8s cluster for tf-controller to run a job on, to completion, and make that another separate pattern that we use for demos and examples.

Any thoughts before I go ahead and implement such a process? (Does this sound like a good idea at all?)

@stefanprodan cc @juozasg

[kingdonb]

Reference also:
https://github.com/fluxcd-community/github-app-secret

We have done some work on this problem already, in the fluxcd-community umbrella

[kingdonb]

Got 'em

BOT_GITHUB_TOKEN is the secret, (fixed in 18067de)