Skip to content
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

Merged
merged 10 commits into from
Jan 31, 2023

Conversation

nicolasfara
Copy link
Contributor

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 the macOS 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:

graph TD
  A[Create staging repository] -- repositoryId --> B[Linux Runner]
  A -- repositoryId --> C[macOS Runner]
  A -- repositoryId --> D[Windows Runner]
  B --> T1[...]
  C --> T2[...]
  D --> T3[...]
Loading

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!

@DanySK
Copy link
Owner

DanySK commented Jan 29, 2023

Also update README.md with an explanation of how the feature is meant to work. There should be a way to export the repoId somehow

@codecov
Copy link

codecov bot commented Jan 29, 2023

Codecov Report

Base: 0.00% // Head: 0.00% // No change to project coverage 👍

Coverage data is based on head (335599b) compared to base (8aac450).
Patch coverage: 0.00% of modified lines in pull request are covered.

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     
Impacted Files Coverage Δ
...danilopianini/gradle/mavencentral/Configuration.kt 0.00% <0.00%> (ø)
...nini/gradle/mavencentral/NexusStatefulOperation.kt 0.00% <0.00%> (ø)

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

@nicolasfara
Copy link
Contributor Author

Update the readme with an explanation of how to use the feature. Moreover, I've implemented a way to export the repositoryId as an output of a step in CI.

@DanySK
Copy link
Owner

DanySK commented Jan 30, 2023

Nice, but it is tailored to Github Actions alone.
Proposal: let us write the repoId on a file in the build folder (which is the standard Gradle way of creating outputs), in file that might be something like staging-repo-ids.properties, regardless of it being CI or not.

Then, who uses GHA will cat build/staging-repo-ids.properties >> $GITHUB_OUTPUTS themselves.

How does it sound?

@DanySK
Copy link
Owner

DanySK commented Jan 30, 2023

@nicolasfara do you want this branch to be kept up-to-date? And if so, do you prefer merge or rebase?

@nicolasfara
Copy link
Contributor Author

Nice, but it is tailored to Github Actions alone. Proposal: let us write the repoId on a file in the build folder (which is the standard Gradle way of creating outputs), in file that might be something like staging-repo-ids.properties, regardless of it being CI or not.

Yeah, it sounds very good! I'll implement this feature ASAP 👍🏻

@nicolasfara
Copy link
Contributor Author

nicolasfara commented Jan 30, 2023

@nicolasfara do you want this branch to be kept up-to-date? And if so, do you prefer merge or rebase?

Yes, please! Rebase would be great!

@mergify
Copy link

mergify bot commented Jan 30, 2023

⚠️ This pull request got rebased on behalf of a random user of the organization.
This behavior will change on the 1st February 2023, Mergify will pick the author of the pull request instead.

To get the future behavior now, you can configure bot_account options (e.g.: bot_account: { author } or update_bot_account: { author }.

Or you can create a dedicated github account for squash and rebase operations, and use it in different bot_account options.

@DanySK
Copy link
Owner

DanySK commented Jan 30, 2023

Auto-rebase enabled. Let me know when you're ready for a review round.

@DanySK DanySK added the feat label Jan 30, 2023
@DanySK DanySK changed the title Publish artifacts to an already opened staging repository feat: allow exporting Nexus repository IDs and publishing artifacts to an open Nexus staging repository Jan 30, 2023
@nicolasfara
Copy link
Contributor Author

Ready for code review :)

Copy link
Owner

@DanySK DanySK left a 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

.github/workflows/build-and-deploy.yml Outdated Show resolved Hide resolved
@DanySK DanySK merged commit 5faaaf8 into DanySK:master Jan 31, 2023
DanySK pushed a commit that referenced this pull request Jan 31, 2023
## [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))
@github-actions
Copy link

🎉 This PR is included in version 3.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants