Skip to content
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

Merged
merged 8 commits into from
Feb 13, 2024

Conversation

humitos
Copy link
Member

@humitos humitos commented Dec 20, 2023

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:

  • copy the js file from -ops here to be able to load the script with wrangler
  • add two new NGINX location that proxy to GitHub: this allows us to run the .js file from -ops without any modification
  • use the pre-compiled version of readthedocs-addons.js script to avoid developers to setup all the js environment locally
  • allow to test "local development changes in addons" by simply modifying a URL in the CF Worker file
  • pin versions of wrangler and nodejs for the new Docker container

Closes readthedocs/addons#217
Closes https://github.com/readthedocs/readthedocs-ops/issues/1435
Requires readthedocs/common#192

Comment on lines +17 to +18
const addonsJs =
'<script async type="text/javascript" src="/_/static/javascript/readthedocs-addons.js"></script>';
Copy link
Member Author

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) -- 💯

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Comment on lines 23 to 32
# 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;
}
Copy link
Member Author

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 🚀

Copy link
Member

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>

Copy link
Member Author

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.

Copy link
Contributor

@agjohnson agjohnson Feb 8, 2024

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.

Copy link
Member Author

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.

@humitos humitos marked this pull request as ready for review February 6, 2024 13:02
@humitos humitos requested review from a team as code owners February 6, 2024 13:02
Copy link
Member

@ericholscher ericholscher left a 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 👍

Comment on lines 23 to 32
# 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;
}
Copy link
Member

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;
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

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 😄

Copy link
Member Author

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

Copy link
Contributor

@agjohnson agjohnson left a 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.

Comment on lines +17 to +18
const addonsJs =
'<script async type="text/javascript" src="/_/static/javascript/readthedocs-addons.js"></script>';
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Member Author

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

  1. 8080 is just a random/standard port.

Copy link
Contributor

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?

Copy link
Member

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?

Copy link
Member Author

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.

@humitos
Copy link
Member Author

humitos commented Feb 12, 2024

I still have some questions on how exactly Wrangler operates in front of Proxito, that would be good to clarify more

Do you have specific questions here where I can help?

@humitos humitos requested a review from a team as a code owner February 13, 2024 10:53
@humitos
Copy link
Member Author

humitos commented Feb 13, 2024

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.

@humitos humitos merged commit ea43371 into main Feb 13, 2024
2 of 4 checks passed
@humitos humitos deleted the humitos/wrangler-locally branch February 13, 2024 11:03
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.

Docs: how to run Cloudflare Worker locally (via wrangler)
3 participants