-
Notifications
You must be signed in to change notification settings - Fork 121
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
Reuse Uptest workflow and standardize Makefile targets #116
Reuse Uptest workflow and standardize Makefile targets #116
Conversation
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
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.
Thanks @turkenh, lgtm. And one other thing is we still need to define the referred repo secrets for provider-aws. Who will do that?
|
||
echo "Running setup.sh" | ||
echo "Creating cloud credential secret..." | ||
${KUBECTL} -n upbound-system create secret generic provider-secret --from-literal=credentials="${UPTEST_CLOUD_CREDENTIALS}" --dry-run=client -o yaml | ${KUBECTL} apply -f - |
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 the set of expected environment variables to run the e2e
and uptest
targets documented somewhere?
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.
e2e
is expected to run with CI and uptest
is not different than the previous uptest-local
target. I'll update the docs, e.g. this, accordingly.
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.
Just pushed a new commit adding some comments and a deprecation notice for uptest-local
target.
|
||
echo "Running setup.sh" | ||
echo "Creating cloud credential secret..." | ||
${KUBECTL} -n upbound-system create secret generic provider-secret --from-literal=credentials="${UPTEST_CLOUD_CREDENTIALS}" --dry-run=client -o yaml | ${KUBECTL} apply -f - |
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 reason we dry-run and then pipe to an apply instead of running without the --dry-run
option?
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.
yes, if I don't include that it fails when secret exists.
kubectl create secret generic aws-secret -n upbound-system --from-file=creds=/Users/hasanturken/.aws/credentials -o yaml | kubectl apply -f -
error: failed to create secret secrets "aws-secret" already exists
error: no objects passed to apply
Signed-off-by: Hasan Turken <turkenh@gmail.com>
cf20c77
to
6218917
Compare
@ulucinar pushed a commit and responded your comments, could you have another look? |
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.
Thanks @turkenh, lgtm.
Description of your changes
Consumes reusable workflows introduced in upbound/official-providers-ci#39
Also, standardize Makefile targets and cleans up old script.
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
I'll only be able to test GitHub actions after merging this PR.