-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Development: use wrangler
locally (update NGINX/Dockerfile config)
#10965
Conversation
dcedc4b
to
16ae1ab
Compare
const addonsJs = | ||
'<script async type="text/javascript" src="/_/static/javascript/readthedocs-addons.js"></script>'; |
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.
If we want to test an addon we are developing, we can just change this URL to http://localhost:8000/readthedocs-addons.js
while having npm run dev
running and refresh the page (there is no need to restart Docker or anything) -- 💯
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.
Note, that there is a inv docker.up -w
flag that enables webpack hosting. This would be a good pattern to follow eventually. Making this a manual operation means it won't be repeatable or easy to use.
The development workflow with Webpack dev server hosting these assets is really good and should probably be the default for core team.
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.
Yes. I'm happy to create an issue to track this work. I don't think we have a pattern for "given an environment variable make a decision on an asset file". We will need to change the content of this file in particular, so, it may require some research.
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.
# Proxy the "readthedocs-addons.js" to be downloaded from GitHub | ||
location /_/static/javascript/readthedocs-addons.js { | ||
proxy_pass https://raw.githubusercontent.com/readthedocs/addons/$NGINX_ADDONS_GITHUB_TAG/dist/readthedocs-addons.js; | ||
add_header Content-Type "text/javascript; charset=utf-8" always; | ||
} | ||
|
||
location /_/static/javascript/readthedocs-addons.js.map { | ||
proxy_pass https://raw.githubusercontent.com/readthedocs/addons/$NGINX_ADDONS_GITHUB_TAG/dist/readthedocs-addons.js.map; | ||
add_header Content-Type "text/javascript; charset=utf-8" always; | ||
} |
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 allows us to use the exact same version of the CF Worker script in -ops
than in .org
repositories. Then, each time we deploy a new version of the addons, we can update NGINX_ADDONS_GITHUB_TAG
to point to the newer tag 🚀
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.
Having a rel
branch or similar would be useful here, but probably not worth doing in this 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.
Makes sense. I need to think a little more about this. We are not following the same deploy pattern that with the other repositories, and we are always just doing the deploy from a tag.
I don't know exactly why, but I suppose it was to simplify things when I built the deployment (maybe I copied it from EthicalAds client? 🤔 ). However, it may worth to use the standardize it.
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.
Being explicit here about the version I think is an improvement I feel.
I will say that overall I prefer managing our libraries with standard packaging/versioning, and would love to eventually replace the rel/relcorp pattern with standard dependency management (npm install @readthedocs/addons@1.3.3
) as I think it ends up being confusing coordinating rel/relcorp across all our repos. At very least, using versioning for smaller/newer libraries feels like a step forward.
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.
OK. So, for now, I will keep it as is and we can discuss further if we need to adapt this code in the future.
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 a pretty clean solution 👍
# Proxy the "readthedocs-addons.js" to be downloaded from GitHub | ||
location /_/static/javascript/readthedocs-addons.js { | ||
proxy_pass https://raw.githubusercontent.com/readthedocs/addons/$NGINX_ADDONS_GITHUB_TAG/dist/readthedocs-addons.js; | ||
add_header Content-Type "text/javascript; charset=utf-8" always; | ||
} | ||
|
||
location /_/static/javascript/readthedocs-addons.js.map { | ||
proxy_pass https://raw.githubusercontent.com/readthedocs/addons/$NGINX_ADDONS_GITHUB_TAG/dist/readthedocs-addons.js.map; | ||
add_header Content-Type "text/javascript; charset=utf-8" always; | ||
} |
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.
Having a rel
branch or similar would be useful here, but probably not worth doing in this PR>
|
||
# Wrangler serving | ||
location / { | ||
proxy_pass http://wrangler:8000; |
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.
Would be good to document how this works somewhere.. perhaps in a README as well as update the dev environment docs?
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.
Good point 👍🏼 . I will take a look at our docs and see if it's a good fit there first.
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 added a readme file in 1dd4c55. It's not perfect, but I wasn't sure what else write down there. I hope it helps 😄
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 also updated our dev installation guide in 1830c02
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 looks good, I still have some questions on how exactly Wrangler operates in front of Proxito, that would be good to clarify more. I'm excited to have this in place though, I've struggled to do QA on addons from the local application environment.
const addonsJs = | ||
'<script async type="text/javascript" src="/_/static/javascript/readthedocs-addons.js"></script>'; |
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.
Note, that there is a inv docker.up -w
flag that enables webpack hosting. This would be a good pattern to follow eventually. Making this a manual operation means it won't be repeatable or easy to use.
The development workflow with Webpack dev server hosting these assets is really good and should probably be the default for core team.
@@ -1,7 +1,7 @@ | |||
# Proxito | |||
server { | |||
listen 80 default_server; | |||
server_name $NGINX_PROXITO_SERVER_NAME; | |||
listen 8080; |
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.
Regarding the readme change below, it's not clear to me why proxito is moving to 8080 here. Is wrangler proxying to port 8080 now?
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.
We are moving El Proxito away from port 80. This is because Wrangler is the one listening to 80 now, since it's the first application handling the request at *.devthedocs.org
URLs (documentation URLs).
Once the request is received by Wrangler, it executes our .js
script that performs another request behind the scenes (using fetch
) to El Proxito (NGINX container in port 80801) and gets the "original response". Then, it modifies that response to inject the HTML tags required.
This is exactly how CF works in production.
Does this make sense?
Footnotes
-
8080 is just a random/standard port. ↩
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.
Well I understood the topology of wrangler mimicking Cloudflare in front of all requests, but it's still not clear what exactly is configured to forward to port 8080.
Is this wrangler configuration somewhere? Or are you describing something special in our code to forward to this container/port?
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.
readthedocs/common#192 might make it more clear?
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.
Ah, yeah, this PR does not show how the wrangler
command is executed. The PR that Eric pointed out is the one to take a look and I think it will make it more clear 👍🏼 . Let me know if this is still confusing.
Do you have specific questions here where I can help? |
I will merge this PR so we can move forward with this and other folks can try it as well. I'm happy to add any other feedback you may have in a following PR. |
Use
wrangler
(development CF Worker) to run the CF worker locally inside our development environment. This allow us to run the exact same code locally than on production, allowing us to perform tests while making modifications on this script without deploying them.With the current code, developers shouldn't notice anything different and they don't have to do anything. Addons should just work on projects that have Addons enabled the next time they call
inv docker.up
locally.Some decisions that I made:
readthedocs-addons.js
script to avoid developers to setup all the js environment locallyCloses readthedocs/addons#217
Closes https://github.com/readthedocs/readthedocs-ops/issues/1435
Requires readthedocs/common#192