enable crate maintainers to trigger docs.rs rebuilds from crates.io

[syphar]

This is a first draft because I need more pointers.

• is this how the API could look like? What's missing apart from tests?
• where would I find the frontend parts be? Quoting from zulip: FWIW I think I'd put the button below the docs.rs link in the sidebar of the crates

Generally I imagine that most limits should be applied from docs.rs, like how often a crate maintainer can trigger a rebuild.

[syphar]

cc @GuillaumeGomez

[Turbo87]

is this how the API could look like?

yeah, looks good to me at first glance. as I mentioned in the review comments, we might want to restrict it to cookie-only for now. this gives us a bit more flexibility in evolving the API, if necessary.

What's missing apart from tests?

• frontend implementation incl. tests, though we could also put that in a dedicated PR
• maybe some way to mock this? I'm not entirely sure yet how else we would test this otherwise 😅

where would I find the frontend parts?

the relevant part of the frontend is at

crates.io/app/components/crate-sidebar.hbs

Lines 73 to 79 in fba0b72

	{{#if @version.documentationLink}}
	<CrateSidebar::Link
	@title="Documentation"
	@url={{@version.documentationLink}}
	data-test-docs-link
	/>
	{{/if}}

.

the component we use there isn't particularly flexible at the moment though, so it might need a bit of a refactoring first. I'm happy to take it from here though, unless you want to dive in deeper :)

happy to talk about it in more detail during the all-hands

[syphar]

@Turbo87 thanks for the notes! I'll continue on the API & its tests, mocking the HTTP server.

I'm happy to take it from here though, unless you want to dive in deeper :)

That would take me quite some time, also @GuillaumeGomez offered to help if you don't have time.

[Turbo87]

I'll continue on the API & its tests, mocking the HTTP server.

FWIW I'm wondering if it would make sense to extract a DocsRsClient trait with a corresponding implementation and using mockall::automock, similar to how we do it in the crates_io_github and crates_io_team_repo packages. This would probably remove the need for using an HTTP mock server (mockito) in the main API test suite and restrict it to the tests for the client implementation.

[syphar]

I'll continue on the API & its tests, mocking the HTTP server.

FWIW I'm wondering if it would make sense to extract a DocsRsClient trait with a corresponding implementation and using mockall::automock, similar to how we do it in the crates_io_github and crates_io_team_repo packages. This would probably remove the need for using an HTTP mock server (mockito) in the main API test suite and restrict it to the tests for the client implementation.

I extracted the client and used mockall similar to the other APIs.

Does it look like what you would want?

Then I'll start adding some tests.

( I'll squash the commits in the end )

[syphar]

I think this is ready for another review.

main changes in commits, notable: the docs.rs config now is mandatory, not sure if that's ok? It made the whole App & Environment dance a little easier. Happy to change it again if necessary.

Also, not all cases are covered in the endpoint & job tests. Do we have examples where jobs are unit-tested?

[Turbo87]

Do we have examples where jobs are unit-tested?

crates.io/src/worker/jobs/rss/sync_crate_feed.rs

Line 178 in e38e064

mod tests {

has an example of a background job unit test.

we basically extracted the core logic into a free function and tested that instead.

given the relatively straightforward implementation of the background job, and the fact that the client impl is tested independently, I'm not sure whether we need extensive tests for the background job though.

[syphar]

@Turbo87 from what I see, I covered everything except the frontend?

I'm happy to add any other things that might be missing.

I also manually tested the client via the example in crates_io_docs_rs