-
Notifications
You must be signed in to change notification settings - Fork 9
Improve GitHub API handling #592
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve GitHub API handling #592
Conversation
…ove-github-api-handling-when-populating-metadata
🦋 Changeset detectedLatest commit: a12d367 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…ove-github-api-handling-when-populating-metadata
…ove-github-api-handling-when-populating-metadata
…ove-github-api-handling-when-populating-metadata
/release-pr |
/release-pr |
…ove-github-api-handling-when-populating-metadata
/release-pr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a couple of things about this cachedFetch
helper changed, I'll add tests for them before landing this - let's just focus on the functionality now when reviewing this 😉
if (env.CIRCLE_PULL_REQUEST) { | ||
logger.debug(`Extracting merge id from ${env.CIRCLE_PULL_REQUEST}`); | ||
logger.info("GetCircleCIMergeId:WillExtract", { circlePullRequest: env.CIRCLE_PULL_REQUEST }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed the changes done by @miriambudayr here: #589
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice cleanup. I left a few suggestions in cachedFetch
but otherwise looks good
packages/shared/src/cachedFetch.ts
Outdated
statusText: resp.statusText, | ||
}); | ||
} | ||
} catch (err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pet peeve of mine 😅
} catch (err) { | |
} catch (error) { |
packages/shared/src/cachedFetch.ts
Outdated
if (shouldRetryFn) { | ||
const shouldRetry = await shouldRetryFn(resp); | ||
const shouldRetry = await shouldRetryFn(resp, json, retryAfter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Previously we only called this function if we still had remaining retries. Now we call it anyway, then potentially bail out immediately. Seems slightly better before? We could probably remove the duplicate return-error by combining these a bit more
let shouldRetry = attempt < maxAttempts;
if (shouldRetry && shouldRetryFn) {
shouldRetry = await shouldRetryFn(resp, json, retryAfter);
}
// ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll cover this with tests, thanks for noticing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair but it's not even really a problem that a test would root out. I'm just saying that we're doing unnecessary work (and there's a bit of unnecessarily duplicated code) :)
`Ignoring metadata key "${key}". Custom metadata blocks must be prefixed by "x-". Try "x-${key}" instead.` | ||
); | ||
if (opts.verbose) { | ||
console.log( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just double checking that you meant to console.log
here instead of logger.log
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably not, I'll recheck this, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intentional because opts.verbose
is meant to output things into the console. Our new logger
doesn't ever do that today
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our new logger doesn't ever do that today
Seems like maybe we should figure out a way to make this change rather than adding one or two console.log
statements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, although their purpose is somewhat different. It's one thing to log things useful to us and log things useful to the consumer. They won't always align. Many of our new logs are in tag/label format like:
logger.debug("LaunchBrowser:Stdout", { text });
From what I understand this is a format that should (eventually) be used by all of those logger calls. But with that I'm not sure what we should do when we want to both use the logger and log smth to the user. Something like this?
logger.info("SanitizeMetadata:IgnoringKey", {
key
verbose: verbose && `Ignoring metadata key "${key}". Custom metadata blocks must be prefixed by "x-". Try "x-${key}" instead.`
});
I think it's probably super bikesheddable and it could easily be put in a followup task
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah totally. Sorry I didn't mean to suggest that was a blocker for merging this :)
…ove-github-api-handling-when-populating-metadata
No description provided.