Build using local dependencies, re-enable CI #13
Conversation
dblock
force-pushed
the
build-local-ci
branch
12 times, most recently
from
6ae0c46
to
0186f2b
Compare
Signed-off-by: dblock <dblock@amazon.com>
dblock
force-pushed
the
build-local-ci
branch
3 times, most recently
from
2d4a802
to
1cd53c7
Compare
Signed-off-by: dblock <dblock@amazon.com>
Signed-off-by: dblock <dblock@amazon.com>
dblock
changed the title
.github/workflows/CI.yml
Outdated
| - name: Checkout common-utils | ||
| uses: actions/checkout@v2 | ||
| with: | ||
| repository: 'dblock/common-utils' |
There was a problem hiding this comment.
Minor: can we avoid using a personal repository name?
Ignore this comment if this is just WIP/temporary solution/testing purpose.
There was a problem hiding this comment.
Actually not that minor. This is opensearch-project/common-utils#4 that would need to be merged and that's incompatible with the current S3 build setup - the whole build fails without S3 ENV regardless of whether you try to build to maven local or not.
There was a problem hiding this comment.
Got it. I mean it's good to remove this personal S3 maven repo url = 's3://search-vemsarat/', but seems we use another personal local path with name 'dblock/....
Currently it's not convenient to build/test locally. Will we publish all dependencies to public maven/integrate with jitpack soon?
There was a problem hiding this comment.
The personal path is just pending PRs being merged if we decide to go this route.
We'll (I'll) evaluate jitpack to compare. It currently doesn't "just work", needs to successfully be able to check out and build these dependencies.
There was a problem hiding this comment.
+1, once we evaluate jitpack, we should make changes to common-utils and job-scheduler, build them locally here in the workflows instead of fork repositories.
dblock
changed the title
dblock
changed the title
dblock
changed the title
Signed-off-by: dblock <dblock@amazon.com>
Signed-off-by: dblock <dblock@amazon.com>
| mavenCentral() | ||
| maven { url "https://plugins.gradle.org/m2/" } | ||
| maven { |
There was a problem hiding this comment.
By removing this private S3 maven, can we use ./gradlew build to build AD plugin locally?
There was a problem hiding this comment.
Btw the S3 credentials being required could also be worked around by tagging ?: '' to them.
There was a problem hiding this comment.
After removing this s3 maven, I think we need build all of other dependencies and publish them to local maven repo in our laptop, just similar as the CI workflow to make the local ./gradlew build work, right?
There was a problem hiding this comment.
Correct, run ./gradlew publishToMavenLocal on each dependency once.
Signed-off-by: dblock <dblock@amazon.com>
Signed-off-by: dblock <dblock@amazon.com>
|
This is now ready to merge. |
| @@ -111,6 +112,7 @@ public void tearDown() throws Exception { | |||
| super.tearDownLog4jForJUnit(); | |||
| } | |||
|
|
|||
| @Ignore | |||
There was a problem hiding this comment.
Just curious why these tests are not working?
There was a problem hiding this comment.
Not sure, they are legit flaky, but I opened #15 to address.
ohltyler
added
the
infra
Signed-off-by: dblock dblock@amazon.com
Description
Fixes CI by building all the dependencies.
Only runs tests, no integ tests, packaging or distribution.
WDYT? Would need to fix all the stuff I removed from CI and the 4 failing tests afterwards, but does give us a green build.
Depends On
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.