-
Notifications
You must be signed in to change notification settings - Fork 6
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: allow exporting Nexus repository IDs and publishing artifacts to an open Nexus staging repository #471
Conversation
Also update |
Codecov ReportBase: 0.00% // Head: 0.00% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## master #471 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 11 11
Lines 371 378 +7
Branches 30 31 +1
======================================
- Misses 371 378 +7
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Update the readme with an explanation of how to use the feature. Moreover, I've implemented a way to export the |
Nice, but it is tailored to Github Actions alone. Then, who uses GHA will How does it sound? |
@nicolasfara do you want this branch to be kept up-to-date? And if so, do you prefer merge or rebase? |
Yeah, it sounds very good! I'll implement this feature ASAP 👍🏻 |
Yes, please! Rebase would be great! |
To get the future behavior now, you can configure Or you can create a dedicated github account for squash and rebase operations, and use it in different |
Auto-rebase enabled. Let me know when you're ready for a review round. |
Ready for code review :) |
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 a clarification on the new test
## [3.2.0](3.1.1...3.2.0) (2023-01-31) ### Features * allow exporting Nexus repository IDs and publishing artifacts to an open Nexus staging repository ([#471](#471)) ([5faaaf8](5faaaf8)) ### Bug Fixes * solve a problem where the task fail if the build folder is not previously created ([#473](#473)) ([8d8a9a3](8d8a9a3)) ### Dependency updates * **deps:** update dependency semantic-release-preconfigured-conventional-commits to v1.1.16 ([9764050](9764050)) ### Build and continuous integration * **deps:** update alchemistsimulator/alchemist action to v25.4.2 ([240670b](240670b)) * **deps:** update alchemistsimulator/alchemist action to v25.5.0 ([0333630](0333630)) * **deps:** update alchemistsimulator/alchemist action to v25.6.0 ([1a7dee5](1a7dee5)) * **deps:** update alchemistsimulator/alchemist action to v25.7.0 ([ef52476](ef52476)) * **deps:** update alchemistsimulator/alchemist action to v25.7.1 ([2576f48](2576f48)) * **deps:** update alchemistsimulator/alchemist action to v25.7.2 ([fbbe71c](fbbe71c)) * **deps:** update alchemistsimulator/alchemist action to v25.8.0 ([8aac450](8aac450)) * **deps:** update danysk/build-check-deploy-gradle-action action to v2.1.21 ([71de72b](71de72b))
🎉 This PR is included in version 3.2.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This PR aims to improve the plugin to better manage the upload artifacts in different stages.
Rationale
Sometimes could be useful to configure the plugin to publish artifacts to a specific staging repository.
For example, in Kotlin KMP projects, each OS runner should publish all the relative artifacts to the same staging repository.
At the moment, this problem is solved by running all the publishing tasks on a
macOS
runner since can cross-compile for all the other platforms (iOS, win, Linux, etc.). This causes themacOS
runner to run for a very long time ~45 minutes which could cause a high cost.At the moment, this plugin creates a new staging repository for each run, causing the creation of a separate staging repository for each runner OS despite all the artifacts belonging to a single release.
The feature introduced in this PR tries to enable you to specify which repository should be used to upload the artifacts by declaring the
nexusStagingRepositoryId
gradle property.In this way, we could define a CI workflow as follow:
A job is responsible to create the staging repository. Then, the repo id is shared with each runner so that all the artifacts will be uploaded to the right repository.
If I have not missed anything, this should restrict the responsibility to each runner (host platform) to release the corresponding target platform into the shared staging repository. Moreover, this has the advantage of not overloading the
macOS
runner, turning into an economic saving.If I have missed something or you have more ideas on how to improve this aspect, let me know!