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
Update routes for code docs launch, using a dcdo flag #45145
Conversation
d6f9e3e
to
2059beb
Compare
05844e2
to
f6c5f01
Compare
… and grabbing the title in the level
8ee6ccc
to
e40af56
Compare
Since we will continue to have old Map levels which point to CB I think it would be better to leave this level and then add a new one that uses the new reference guides |
return | ||
end | ||
programming_environment.assign_attributes(programming_environment_params.except(:categories)) | ||
return render :not_found unless @programming_environment |
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.
love that you moved to using @programming_environment
here. You can also move this not_found check into set_programming_environment
so you don't have to check it in each controller.
@@ -62,7 +62,10 @@ | |||
|
|||
get 'redirected_url', to: 'redirect_proxy#get', format: false | |||
|
|||
get 'docs/', to: 'curriculum_proxy#get_doc_landing' | |||
get 'docs/', to: 'programming_environments#docs_index' |
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.
Are there unit tests that could be added to check that all of these URLs go to the right place and that ones that should go to CB for concept maps aren't impacted?
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 forgot to add one for this route but the fact that this test still passes is evidence that concept maps aren't affected.
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.
Great. Thanks for pointing to existing tests that are covering this
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.
hmm, my understanding is that controller tests do not look at our routing logic, so I think that test is verifying that the curriculum proxy controller does the right thing, but not that the right requests will get routed to the curriculum proxy controller. to test the routing, you'd need an integration test which operates on urls, maybe like one of these:
get '/home' get '/beta'
given how much complexity there is in the routing logic, I think it would be a good idea to have at least one integration test verifying that the fallback to /docs/concepts on CB is working end-to-end.
I just updated this level to point to a /docs/concepts route off curriculum builder. The reason I did this is that no levels use /docs/ in a map level so it didn't seem super helpful to test. I can add a new level though if it would help to keep this consistent, but I definitely think we need a Map level for /docs/concepts to be tested |
Ah ok I understand the difference now. It's a Map Level with a Code Doc. My head had not switched out of Ref Guides world so thank you for explaining |
@davidsbailey I would love for you to take a look too as I'm not super familiar with DCDO flags and proxied urls. |
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.
sorry for the long delay. DCDO code and tests look good!
get 'docs/', to: 'programming_environments#docs_index' | ||
get 'docs/:programming_environment_name', to: 'programming_environments#docs_show', constraints: {programming_environment_name: /(applab|gamelab|spritelab|weblab)/} | ||
get 'docs/:programming_environment_name/:programming_expression_key', constraints: {programming_environment_name: /(applab|gamelab|spritelab|weblab)/, programming_expression_key: /#{CurriculumHelper::KEY_CHAR_RE}+/}, to: 'programming_expressions#docs_show' | ||
get 'docs/:programming_environment_name/:programming_expression_key/index.html', constraints: {programming_environment_name: /(applab|gamelab|spritelab|weblab)/, programming_expression_key: /#{CurriculumHelper::KEY_CHAR_RE}+/}, to: 'programming_expressions#docs_show' | ||
get 'docs/*path', to: 'curriculum_proxy#get_doc' |
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.
am I correct in understanding that this line handles the following routes mentioned in the PR description?
we will continue to proxy /docs/concepts, /docs/csd, /docs/csd-1718, etc and I was having trouble coming up with a good allow-list for all the various routes we use (but I could if needed).
if so, this would be helpful to note in a comment on this line. also, what is the endgame for /docs/csd and /docs/csd-1718 -- will we continue to proxy these requests to curriculum builder indefinitely?
@tim-dot-org , heads up that you'll need to modify this routing when you launch concept maps. it looks like you should just be able to add any new routing rules above this line.
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.
Yep these routes only direct requests to /docs/{applab,gamelab,spritelab,weblab} to the new controllers. Everything else will still go to curriculum_proxy. Because there are all these other routes in our curriculum, I figured it would be better to explicitly list these exceptions.
I don't know what the endgame is for those routes. Older levels, such as https://levelbuilder-studio.code.org/s/csd2-2019/lessons/3/levels/7, link to these routes in the "Help and Tips" tab, but it looks like some of them were replaced by concept maps (eg the same level in 2020). It might be possible to pull support for these routes but a. I'm not sure and b. this doesn't seem like something we'll have time for before curriculum launch.
@@ -62,7 +62,10 @@ | |||
|
|||
get 'redirected_url', to: 'redirect_proxy#get', format: false | |||
|
|||
get 'docs/', to: 'curriculum_proxy#get_doc_landing' | |||
get 'docs/', to: 'programming_environments#docs_index' |
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.
hmm, my understanding is that controller tests do not look at our routing logic, so I think that test is verifying that the curriculum proxy controller does the right thing, but not that the right requests will get routed to the curriculum proxy controller. to test the routing, you'd need an integration test which operates on urls, maybe like one of these:
get '/home' get '/beta'
given how much complexity there is in the routing logic, I think it would be a good idea to have at least one integration test verifying that the fallback to /docs/concepts on CB is working end-to-end.
If I change these tests to have a random name for the programming environments, the tests actually fail with |
test '/docs/applab is routed to ProgrammingEnvironmentsController' do | ||
assert_recognizes( | ||
{controller: 'programming_environments', action: 'docs_show', programming_environment_name: 'applab'}, | ||
{path: '/docs/applab', method: :get} |
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 pattern! TIL
Adds a DCDO flag to toggle where we serve code docs from. At first, it will continue to proxy these pages from curriculum builder. When the DCDO flag is flipped, it will use the levelbuilder versions of this page. I chose to use a DCDO flag as with my team moves, it's a lower lift to launch these pages whenever we like.
The implication of the way I've done this change is that the /docs URLs will only work for applab, gamelab, spritelab, and weblab code docs. These urls are difficult to handle in our Rails application, as we will continue to proxy /docs/concepts, /docs/csd, /docs/csd-1718, etc and I was having trouble coming up with a good allow-list for all the various routes we use (but I could if needed). Starting with javalab, I'd like to start using more Rails-friendly routes for these pages.
This PR will cause an eyes diff as I switched out one of the allthethings levels. The only time we have used a code docs page in a CurriculumReference/Map level was this allthethings level, so I switched it to use a reference guide instead.
Testing story
a fair number of existing tests tested this functionality, added more unit tests, manual testing
Deployment strategy
This should be safe to deploy as the page doesn't change, just the controller action. This is also not a route that is used for ajax requests on a page.
Follow-up work
after these pages are launched, there's a bit of clean up to do here
PR Checklist: