Add nmcpPublishCentralPortalDeployment task#251
Add nmcpPublishCentralPortalDeployment task#251marcphilipp wants to merge 2 commits intoGradleUp:mainfrom
nmcpPublishCentralPortalDeployment task#251Conversation
| set -x | ||
| ./gradlew -p tests/jvm build | ||
| ./gradlew -p tests/kmp publishAggregationToCentralPortal --configuration-cache | ||
| ./gradlew -p tests/kmp nmcpPublishCentralPortalDeployment -PnmcpDeploymentId=599ab6f5-dd08-4e7b-ae5a-85b45031715a --configuration-cache |
There was a problem hiding this comment.
Is there a way to use task options with Gratatouille?
There was a problem hiding this comment.
Ha! I knew there was a reason why I wanted to do a CLI...
You're right there is nothing like this in Gratatouille. As much as I love being pragmatic for nmcp, I don't want to encourage this pattern in Gratatouille. If the property works for you, I'd keep things like this.
| set -x | ||
| ./gradlew -p tests/jvm build | ||
| ./gradlew -p tests/kmp publishAggregationToCentralPortal --configuration-cache | ||
| ./gradlew -p tests/kmp nmcpPublishCentralPortalDeployment -PnmcpDeploymentId=599ab6f5-dd08-4e7b-ae5a-85b45031715a --configuration-cache |
There was a problem hiding this comment.
Ha! I knew there was a reason why I wanted to do a CLI...
You're right there is nothing like this in Gratatouille. As much as I love being pragmatic for nmcp, I don't want to encourage this pattern in Gratatouille. If the property works for you, I'd keep things like this.
| } | ||
|
|
||
| logger.lifecycle("Nmcp: put '${request.url}' failed (${result}), retrying... (attempt ${attempt + 1}/${attemptCount})") | ||
| logger.lifecycle("Nmcp: ${request.method} '${request.url}' failed (${result}), retrying... (attempt ${attempt + 1}/${attemptCount})") |
|
|
||
| if (kind == Kind.aggregation) { | ||
| registerNmcpPublishDeploymentTask( | ||
| taskName = "nmcpPublishCentralPortalDeployment", |
There was a problem hiding this comment.
Nit, I'd go with just "nmcpPublishDeployment" because I don't think it's too ambiguous. No strong opinion though, I'm fine leaving this as is if you prefer.
|
Could you please approve the workflow runs? |
Done 👍 Sorry I missed that! |
|
Once again, please 🙏 The way the integration tests are orchestrated seems unconventional and confusing to me. Would you be open to converting them to "regular" functional test using a testing framework of your choice? If so, I'd like to do that first |
Done
Are you thinking about testKit ? TestKit is useful to test cacheability, different Gradle versions or error messages but in order to assert success, they introduce another layer of indirection and I've grown to dislike them, not to mention that they behave differently in some cases. The integration tests here are just regular builds, open Edit: in all cases, looks like the tests passed 🎉 Is this good to merge? |
2 participants
Part of #250.