Fetch funding information and store in the database #2712
Conversation
daveverwer
force-pushed
the
fetch-funding
branch
from
3e4b858 to
918dc8d
Compare
Sources/App/Core/Github.swift
Outdated
| case patreon | ||
| case tideLift | ||
|
|
||
| private static let gitHubApiEncodings: [String: Platform] = [ |
There was a problem hiding this comment.
This (and the associated init(from:)) feels a little weird, but I think it's better than having two different enums that have the same cases but different raw values, and it's certainly better than having the SCREAMING_SNAKE_CASE in our database JSON.
There was a problem hiding this comment.
Do I understand correctly that the API can send both COMMUNITY_BRIDGE and communityBridge as possible values and that's why we have to do this?
|
There's a small issue with some of the URLs coming back with |
daveverwer
force-pushed
the
fetch-funding
branch
from
2872a98 to
e223c50
Compare
|
You mean coming back from the GH API, right? I.e. there's nothing really to be done on our end for now, except see what we get and consider perhaps automatically amending the URLs at some point? |
Sources/App/Models/Repository.swift
Outdated
| @@ -131,6 +134,7 @@ final class Repository: Model, Content { | |||
| defaultBranch: String? = nil, | |||
| firstCommitDate: Date? = nil, | |||
| forks: Int = 0, | |||
| fundingLinks: [Github.FundingLink] = [], | |||
There was a problem hiding this comment.
Admittedly a bit of a nitpick but I think we should avoid "leaking" GH entities into the db model. I'm not proposing a major change here, just to lift FundingLink out of the Github namespace into a plain model inside App/Models - effectively alongside for instance Release, which is a similar entity we're getting from GraphQL.
It'll require a little type shuffle and mapping (just like for release). I'll propose the change in a PR.
(Apart from just "feeling" nicer it'll avoid referencing Github types outside GH specific ingestion and will make it easier to add other services alongside it - if we ever end up doing that 😅)
Move funding type to top level
|
Merging to staging to test today before moving to production. |
Progress towards #2711
This PR implements the first stage of showing funding/sponsorship information: Collecting the data.
I wondered whether to only collect and store the raw data so we always have all the information regardless of whether we have added support for any additional platforms GitHub will support in the future. However, since the data from the YML file does not include complete URLs, we’d also need to add custom support for any new platforms in code so it feels better to keep everything typed in the database. This also allows us to query the data more easily.
This introduces a new GitHub API call, which we should be aware of, but we have plenty of capacity right now. The only alternative would be to collect this data via the builder tool, but if we do that, we should do it for several bits of metadata, including the README and maybe the license. It feels better to keep everything consistent until we get closer to our API token limits.