-
Notifications
You must be signed in to change notification settings - Fork 59
feat: [UEPR-15] Updated script to fix build issues and refactored logic for merging branches #2
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
feat: [UEPR-15] Updated script to fix build issues and refactored logic for merging branches #2
Conversation
…ic for merging branches
ALL_REPOS=" | ||
scratch-audio \ | ||
scratch-desktop \ | ||
scratch-gui \ | ||
scratch-l10n \ | ||
scratch-paint \ | ||
scratch-parser \ | ||
scratch-render \ | ||
scratch-sb1-converter \ | ||
scratch-semantic-release-config \ | ||
scratch-storage \ | ||
scratch-svg-renderer \ | ||
scratch-translate-extension-languages \ | ||
scratch-vm \ |
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.
Even though they are tracked externally, should we leave the removed repos in a comment somewhere around here for future reference? There is a commented out definition of ALL_REPOS
below we could probably reuse. Maybe also changing the comment above the ALL_REPOS
definition to fit the current state of the script would be helpful as well
default_branch () { | ||
BRANCH="" | ||
|
||
if [ -z "$(git -C "${BUILD_TMP}/${REPO_NAME}" branch --list "$BRANCH")" ]; then |
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.
Can this conditional be skipped since the first check is against an empty branch name?
jq "del(.dependencies.\"$DEP\")" "${BUILD_OUT}/workspaces/${REPO}/package.json" | sponge "${BUILD_OUT}/workspaces/${REPO}/package.json" | ||
DEPS="$DEPS $DEP@*" | ||
fi | ||
if jq -e .devDependencies.\"$DEP\" "${BUILD_OUT}/workspaces/${REPO}/package.json" > /dev/null; then | ||
REMOVEDEPS="$REMOVEDEPS $DEP" | ||
jq "del(.devDependencies.\"$DEP\")" "${BUILD_OUT}/workspaces/${REPO}/package.json" | sponge "${BUILD_OUT}/workspaces/${REPO}/package.json" | ||
DEVDEPS="$DEVDEPS $DEP@*" | ||
fi | ||
if jq -e .optionalDependencies.\"$DEP\" "${BUILD_OUT}/workspaces/${REPO}/package.json" > /dev/null; then | ||
REMOVEDEPS="$REMOVEDEPS $DEP" | ||
jq "del(.optionalDependencies.\"$DEP\")" "${BUILD_OUT}/workspaces/${REPO}/package.json" | sponge "${BUILD_OUT}/workspaces/${REPO}/package.json" | ||
OPTDEPS="$OPTDEPS $DEP@*" | ||
fi | ||
if jq -e .peerDependencies.\"$DEP\" "${BUILD_OUT}/workspaces/${REPO}/package.json" > /dev/null; then | ||
REMOVEDEPS="$REMOVEDEPS $DEP" | ||
jq "del(.peerDependencies.\"$DEP\")" "${BUILD_OUT}/workspaces/${REPO}/package.json" | sponge "${BUILD_OUT}/workspaces/${REPO}/package.json" |
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 the duplications in these statements worth extracting in a variable?
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.
Looking good! I have some questions about potential simplification, but if there's a reason to keep it the way it is then I think that's fine :)
|
||
GH_PAGES_BRANCH="gh-pages" | ||
|
||
clone_repository $REPO_NAME |
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.
Is there a way to skip this clone step, since we will already have cloned the repo in add_repo_to_monorepo
? Or is there a reason it needs to be cloned again?
I'm wondering if add_gh_pages
could instead be a special branch handler in the DEST_BRANCH
loop in add_repo_to_monorepo
. Maybe something like:
gh-pages)
add_gh_pages $REPO_NAME
continue
;;
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.
...or possibly even just an "if the branch is gh-pages
then create it a little bit differently" clause in the create the destination branch if it doesn't exist
section of add_repo_to_monorepo
?
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.
The reason is that after we changed once the root to be treated as directory with --to-subdirectory-filter
the rerun of the command with different values keeps the structure created by the first call. This may have a better solution but I decided to not try and over-engineer it.
if [ -z "$(git -C "$BUILD_OUT" branch --list "$GH_PAGES_BRANCH")" ]; then | ||
# create the destination branch if it doesn't exist | ||
git -C "$BUILD_OUT" symbolic-ref HEAD "refs/heads/${GH_PAGES_BRANCH}" | ||
rm -rf "${BUILD_OUT}/.git/index" | ||
git -C "$BUILD_OUT" clean -fdx | ||
git -C "$BUILD_OUT" checkout develop .gitignore | ||
git -C "$BUILD_OUT" add . | ||
git -C "$BUILD_OUT" commit --allow-empty -m "Initial commit for github pages" | ||
else |
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.
Is this different only because a new gh-pages
branch shouldn't contain the source code (and other contents) from develop
? Or is there more going on here?
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.
My intention was to create an orphan branch so that its history is not associated with the branch it is checked out of. However I didn't like the state of the branch after git checkout --orphan
and decided to go with this solution.
scripts/build-monorepo.sh
Outdated
nvm install < .nvmrc | ||
nvm use < .nvmrc |
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 don't think nvm
uses stdin
at all, so I believe these redirects are unnecessary. As long as .nvmrc
is present in the current working directory, this should work the same:
nvm install < .nvmrc | |
nvm use < .nvmrc | |
nvm install | |
nvm use |
scripts/git-batch-push.sh
Outdated
git -C "$BUILD_OUT" push $REMOTE ${h}:refs/heads/$BRANCH --force | ||
done | ||
# push the final partial batch | ||
git -C "$BUILD_OUT" push $REMOTE HEAD:refs/heads/$BRANCH --force |
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.
Is --force
necessary? It makes me nervous about the possibility of something going wrong and causing this to force-push to the wrong branch or repo 😅
If possible, I'd prefer to remove --force
here and instead require a human to prepare the remote branch, maybe with a manual force-push to a base commit.
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.
Yeah, my idea was this value to be replaced with where the fork of the one running the script is, however I didn't make it obvious.
[UEPR-19] Added workflow for building and testing packages
…extensions toolbox categories (#2)
Jira Ticket
UEPR-15
Proposed Changes
Changed the logic for creating monorepo branches and merging code. Added logic that fixes wrong paths after the merge in the monorepo and ensures everything builds properly.