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

release: copy cloudflare assets when promoting #3505

Merged
merged 6 commits into from
Oct 2, 2023

Conversation

MoLow
Copy link
Member

@MoLow MoLow commented Sep 29, 2023

While I believe assets can be copied directly from Jenkins in many cases, I think it is better to start with this approach where everything is promoted from within the www server.

this still doesn't handle the latest soft links. see discussion nodejs/release-cloudflare-worker#33

@richardlau
Copy link
Member

While I realize we do not run the playbook for the www server against the live www server, for my own benefit I'm assuming this needs something similar to #3501 to get the aws client and secrets onto the server?

@richardlau
Copy link
Member

While I realize we do not run the playbook for the www server against the live www server, for my own benefit I'm assuming this needs something similar to #3501 to get the aws client and secrets onto the server?

Actually we probably need to make sure we're okay giving the dist user access to the secrets to publish to R2 storage as that is who the releasers log into the www machine as to do the promotion step.
Refs: https://github.com/nodejs/node/blob/7b624c30b2902375c3c81885fc964b81da0891db/tools/release.sh#L14

@MoLow
Copy link
Member Author

MoLow commented Sep 30, 2023

Actually we probably need to make sure we're okay giving the dist user access to the secrets to publish to R2 storage as that is who the releasers log into the www machine as to do the promotion step.
Refs: nodejs/node@7b624c3/tools/release.sh#L14

Why would that not be ok? these credentials can only access this r2 bucket and nothing else

@MoLow
Copy link
Member Author

MoLow commented Sep 30, 2023

While I realize we do not run the playbook for the www server against the live www server, for my own benefit I'm assuming this needs something similar to #3501 to get the aws client and secrets onto the server?

I already uploaded that manually for the initial file sync, but added to the code for the sake of documentation

@MoLow
Copy link
Member Author

MoLow commented Oct 1, 2023

I'v deployed all files manually besides ansible/www-standalone/tools/promote/resha_release.sh, manually re-created .done files for the last nightly build and promotion was performed to R2: https://r2.nodejs.org/download/nightly/v21.0.0-nightly20231001092fb9f541/

@MoLow
Copy link
Member Author

MoLow commented Oct 2, 2023

https://r2.nodejs.org/download/nightly/v21.0.0-nightly2023100285c09f178c/ was deployed, 100% automatically now

@MoLow MoLow requested a review from richardlau October 2, 2023 07:30
@richardlau
Copy link
Member

Actually we probably need to make sure we're okay giving the dist user access to the secrets to publish to R2 storage as that is who the releasers log into the www machine as to do the promotion step.
Refs: nodejs/node@7b624c3/tools/release.sh#L14

Why would that not be ok? these credentials can only access this r2 bucket and nothing else

I may be being a tad cautious but most releasers (who have access to dist and run the promotion script to promote releases) are not members of build. We currently prevent releasers from changing existing downloads after one week (see #2020) -- I've no idea if that's possible with R2.

#!/bin/sh
find /home/dist/nodejs/ \
-mindepth 2 \
\( -type f -o -type d \) \
-regextype posix-extended \
! -regex '/home/dist/nodejs/[a-z0-9-]*/index.(tab|json)' \
-user dist \
-mtime +7 \
-exec chown root.root '{}' \;

While we do generally trust releasers we have had one incident recently where a releaser lost their laptop which meant we had to revoke their ssh keys to dist. I guess maybe it'd be okay if we're able to rotate the secret used to publish to R2 in the future if we had a similar potential compromise.

@MoLow
Copy link
Member Author

MoLow commented Oct 2, 2023

I guess maybe it'd be okay if we're able to rotate the secret used to publish to R2 in the future if we had a similar potential compromise.

yes, that is possible.

We currently prevent releasers from changing existing downloads after one week (see #2020) -- I've no idea if that's possible with R2.

that will be possible only if we move the entire promotion process to reside inside Cloudflare. (i.e upload to a drafts bucket and promote from within a worker) - but that is a few steps further than where we are at

@MoLow MoLow merged commit b8b63ad into nodejs:main Oct 2, 2023
2 checks passed
@MoLow MoLow deleted the copy-to-cf-from-promote branch October 2, 2023 13:31
@MoLow
Copy link
Member Author

MoLow commented Oct 2, 2023

updated files manually

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.

2 participants