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

www: create script to free space by removing old builds #3199

Merged
merged 6 commits into from
May 15, 2023
Merged

Conversation

sxa
Copy link
Member

@sxa sxa commented Feb 17, 2023

Script as described in #3125

This is the script which will clear up the nightlies and v8-canary directories so they do not constantly increase the disk space. If we are happy with this logic we can determine how to run it - either

  • As a part of the release process before or after copying new builds there
  • Via a regular cron job
  • Something else?

Signed-off-by: Stewart X Addison <sxa@redhat.com>
@sxa sxa self-assigned this Feb 17, 2023
@mhdawson
Copy link
Member

I think a regular cron job would likely be better versus adding something that might affect/delay releases.

@targos
Copy link
Member

targos commented Feb 22, 2023

Most releasers don't have the permissions to change old files anyway.

@sxa
Copy link
Member Author

sxa commented Mar 3, 2023

@mhdawson @targos (and @richardlau just because he's been involved) are you ok with the logic in the script? I don't want to make it live with automation until it's been eyeballed (approved) by others for potential issues.

@targos
Copy link
Member

targos commented Mar 4, 2023

I'm sorry I'm not familiar enough with shell scripts to review this with confidence.

[ $# -lt 2 ] && echo Usage: $0 '[nightly|v8-canary]' '[show|delete]' && exit 1
PRODUCT=$1
[ "$1" != "nightly" -a "$1" != "v8-canary" ] && echo Parameter mist be one of: nightly v8-canary && exit 1
if [ "$2" = "show" ]; then
Copy link
Member

Choose a reason for hiding this comment

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

👍 nice feature, although this would normally be "dry-run" in most commands that do this

Copy link
Member Author

Choose a reason for hiding this comment

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

Was very useful when I was being paranoid during testing ;-) Yep happy to rename it

tools/wwwspace/prune.sh Outdated Show resolved Hide resolved
tools/wwwspace/prune.sh Outdated Show resolved Hide resolved
tools/wwwspace/prune.sh Outdated Show resolved Hide resolved
tools/wwwspace/prune.sh Outdated Show resolved Hide resolved

# Versions from the last two calendar years except last two months
# Keep every date number ending in 1 (So 01 11 21 31)
SELECTED=`ls -1d v${VERSION}.* | egrep "${PRODUCT}$THISYEAR|${PRODUCT}$LASTYEAR" | egrep -v "${PRODUCT}${THISMONTH}|${PRODUCT}${LASTMONTH}" | grep -v ${PRODUCT}20.....1 | grep -v "${LATEST}"`
Copy link
Member

Choose a reason for hiding this comment

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

these regexes are fairly lose, is it worth being specific with ^ and/or $ to bound them properly?

Copy link
Member Author

Choose a reason for hiding this comment

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

The issue is that with names like v20.0.0-nightly20230222a3211e18b4 it means regexping the whole thing which I'd suggest makes it more complex than it needs to be. $PRODUCT should be an adequate start position (I could use ^v${VERSION}.* at the start and [0-9a-e]$ at the end though I guess although I'm not sure we'll hit a situation where that would make much of a difference.

Maybe if someone renamed a file to have a -KEEPME suffix or similar that they wanted to retain?

tools/wwwspace/prune.sh Outdated Show resolved Hide resolved
Copy link
Member

@rvagg rvagg left a comment

Choose a reason for hiding this comment

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

Functionally this seems fine to me, my critique is mostly just personal preference; so that that as you want. I would have leaned on:

  1. Heavier use of quoting
  2. No backticks, $() only
  3. More use of find with its ability to do date stuff; but what you've got here seems perfectly reasonable since we're doing nice date things in file/dir names.

@nschonni
Copy link
Member

nschonni commented Mar 6, 2023

I'm not sure if some the Shellcheck rules will catch those https://github.com/nodejs/build/blob/main/.shellcheckrc. Never took another pass at cleaning any more of them up

sxa and others added 5 commits March 8, 2023 12:05
Co-authored-by: Rod Vagg <rod@vagg.org>
Co-authored-by: Rod Vagg <rod@vagg.org>
Co-authored-by: Rod Vagg <rod@vagg.org>
Co-authored-by: Rod Vagg <rod@vagg.org>
Signed-off-by: Stewart X Addison <sxa@redhat.com>
@sxa
Copy link
Member Author

sxa commented Apr 28, 2023

Verified that this is still behaving as it should after all the changes from the comments.
Script is in /home/dist/prune.sh on the server for anyone with access to take a look at (obviously needs to be run as root or dist to be able to run with the delete option. Not yet in the crontab.

I feel it's a bit safer to have a script like this manually updated, but the cron job could pull it down directly from the nodejs/build repository. I suspect it won't need to be updated too often though. It's currently in ~dist but owned by root to reduce the risk of it being changed but open to options on that.

@sxa
Copy link
Member Author

sxa commented Apr 28, 2023

I'm not sure if some the Shellcheck rules will catch those https://github.com/nodejs/build/blob/main/.shellcheckrc. Never took another pass at cleaning any more of them up

It looks like this is passing the github shellcheck check - I assume that means it's in line with that configuration?

@mhdawson
Copy link
Member

mhdawson commented May 1, 2023

@sxa I would assume that.

@sxa
Copy link
Member Author

sxa commented May 15, 2023

Merging since there have been no objections

@sxa sxa merged commit c53f448 into nodejs:main May 15, 2023
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.

5 participants