Less GitHub dependence #108
Conversation
| project_id: i64, | ||
| owner_id: i64, |
There was a problem hiding this comment.
what do we even do with these? Presumably we only trust the JWT derived ids on the server?
There was a problem hiding this comment.
That's correct, I don't even see us deserializing these fields on the server, but I'm trying to keep this simple mechanical moves. Next PR is contentful. :)
| tracing::debug!( | ||
| "Getting revision count locally failed, using data from github instead" | ||
| ); | ||
| github_graphql_data_result.rev_count | ||
| } |
There was a problem hiding this comment.
hmmm. not a blocker but can we just get rid of it completely? what scenarios does from_git_root fail, and does the rest of the push process still work even in that case?
There was a problem hiding this comment.
Generally github action clones are shallow if I recall? I'm not sure I remember. I'm hoping to get rid of querying this data entirely.
|
FYI: this was reverted in #110 because it caused rolling version numbers to be calculated incorrectly. |
Furthers the cause of #107 and extracts out all the github-fetched data into
src/cli/mod.rsfor now, such thatpush_new_releaseandReleaseMetadata::buildare no longer dependent on the github related structs. This should make opening up other code forges easier.There should be no material code changes here, only refactoring.