-
Notifications
You must be signed in to change notification settings - Fork 452
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
Create a script to create a build drop to enable running functional tests on boxes that didn't build the product. #466
Conversation
Scripts/Mac/LayoutFunctionalTests.sh
Outdated
. "$(dirname ${BASH_SOURCE[0]})/InitializeEnvironment.sh" | ||
|
||
CONFIGURATION=$1 | ||
LAYOUT_ROOT=$2 |
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 think the meaning of "layout" will become fuzzy very quickly. This script is just creating a build drop that can be published from one build and then consumed from another, right?
How about the name CreateBuildDrop.sh
for the script name, and BuildDrop
anywhere you use Layout
inside the script?
I also didn't find an equivalent script for Windows, how is it being created there?
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.
BuildDrop
makes sense. I'll retool this.
I'm going to create a similar script for Windows. I kept it out of this PR in the interest of focus, so I don't have to hop between two boxes. It will the new PR I post. :)
Scripts/Mac/LayoutFunctionalTests.sh
Outdated
@@ -0,0 +1,30 @@ | |||
#!/bin/bash |
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 had discussed reorganizing the Windows scripts into dev-oriented and CI-oriented scripts. This one very clearly feels like a script intended for use on the CI/PR builds, and never on a dev box, so we could we stick it in a different location and not mix it in with the dev scripts?
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'll move it.
3627a94
to
7a960e4
Compare
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.
General questions and one typo otherwise looks good.
Scripts/Mac/CI/CreateBuildDrop.sh
Outdated
# Set up some paths | ||
BUILDDROP_BUILDOUTPUT=$BUILDDROP_ROOT/BuildOutput | ||
BUILDDROP_SRC=$BUILDDROP_ROOT/src | ||
BUILDDROP_PROJFS=$BUILDDROP_SRC/ProfFS.Mac |
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.
ProjFS.Mac?
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.
(facepalm)
mkdir -p $BUILDDROP_BUILDOUTPUT | ||
mkdir -p $BUILDDROP_SRC | ||
mkdir -p $BUILDDROP_PROJFS | ||
mkdir -p $BUILDDROP_KEXT |
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.
There are cases in the build scripts that use sudo
. How do we know when we will need to use that vs not?
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'm making the assumption in this script that the CI agent will have access to wherever it is asked to publish the drop. Also, this caught my clumsiness a few times where I fat fingered /[something] instead of ~/[something].
rsync -avm $VFS_OUTPUTDIR/Git $BUILDDROP_BUILDOUTPUT | ||
rsync -avm $VFS_PUBLISHDIR $BUILDDROP_ROOT | ||
rsync -avm $VFS_SCRIPTDIR $BUILDDROP_SRC/Scripts | ||
rsync -avm $VFS_SRCDIR/ProjFS.Mac/Scripts $BUILDDROP_PROJFS |
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.
Should this keep the Scripts
folder?
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.
It keeps the script folders so that we can keep the logic on how we run functional tests or install/start the kext encoded in the script.
…onal tests on other machines
7a960e4
to
11ab1fb
Compare
This will drop the minimal layout to successfully run the functional tests for a build that can be transferred to a box that did not build the product.