Skip to content

Refactor actions.Client with options to help extensibility#2193

Merged
rentziass merged 2 commits into
masterfrom
rentziass/client-refactor
Jan 23, 2023
Merged

Refactor actions.Client with options to help extensibility#2193
rentziass merged 2 commits into
masterfrom
rentziass/client-refactor

Conversation

@rentziass

Copy link
Copy Markdown
Member

This is a refactor of actions.Client to help extensibility for the upcoming work for supporting proxies and custom TLS. Sorry for the big diff, most of it is test changes to adopt the new API. The notable changes are:

  • change NewClient signature to only require the bare minimum a Client needs to function correctly, and move every other kind of configuration into a ClientOption. This is both to help ease extending the client and to make it easier to rely on NewClient within tests: the more logic we add to a client, the more manually instantiating one becomes error prone.
  • A client is created with an HTTP client that will be used for all requests (at the moment we are creating one per request)
  • to encourage the use of NewClient, newActionsServer is now available in tests.
  • UpdateRunnerScaleSet and UpdateRunnerScaleSet methods were removed, I couldn't find any uses of these?
  • By default logs in tests are silent

assert.Equal(t, want, got)
})

t.Run("Default retries on server error", func(t *testing.T) {

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the HTTP client is now persisted across requests, should we test that the client itself has retries or do we need to keep testing retries on all calls?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer the latter because we can ensure all calls use the retryable client or its equivalent!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But given that the HTTP client is now re-used for the whole lifetime of an actions.Client wouldn't it make sense to have tests that verify that the option of having (or not) retries is observed? The only way to change the HTTP client down the line is for callers of this package to manually change client.Client, but then I would argue it's that caller to test responsibility that their override is working as intended. What do you think?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merging now to unlock other work on expanding the client, but definitely interested in this conversation!

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello! Thank you for your contribution.

Please review our contribution guidelines to understand the project's testing and code conventions.

Comment thread github/actions/client.go

retryClient := retryablehttp.NewClient()

// TODO: this silences retryclient default logger, do we want to provide one

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great if we could selectively enable the logging, for example, let retryablehttp log requests only when the log level is DEBUG or finer.
That way I'd be able to set the log level to DEBUG when I'm curious why job run delays are unusually long and the retrylablehttp logs would reveal that it's due to excessive retries caused by e.g. an actions service incident.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, we'd better address that in another pull request, if necessary, to avoid scope creeping this one!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want to have some logging on error cases, especially to log out some HTTP headers so we can check telemetry on the GitHub service.
Ex: x-github-activity-id, ActivityId, etc.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, it doesn't have to be this PR. 😄

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks both, I'll look at this separately. It's a bit of a pain that retryablehttp wants a different interface for logging, it'd be great not to have to care about it 😄

@mumoshu mumoshu left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Awesome job @rentziass!!

Comment thread github/actions/client.go
return createdRunnerScaleSet, nil
}

func (c *Client) UpdateRunnerScaleSet(ctx context.Context, runnerScaleSetId int, runnerScaleSet *RunnerScaleSet) (*RunnerScaleSet, error) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we not using UpdateRunnerScaleSet anywhere? 😄

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was very surprised, but the only use of it was in its own test 😄

@nikola-jokic nikola-jokic left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me!

@rentziass rentziass merged commit 3327f62 into master Jan 23, 2023
@rentziass rentziass deleted the rentziass/client-refactor branch January 23, 2023 11:50
unpollito pushed a commit to DistruApp/actions-runner-controller that referenced this pull request Jan 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants