Issue with Maven publishing and build failure in Android Gradle Plugin 8.0

[dzuluaga]

I encountered a problem while testing the releases of the project on GitHub. After creating a release on GitHub, the build and publish process for the Maps API were triggered. However, the build failed with the following warning messages during the configuration of the projects:

Configure project :maps-api
WARNING: Software Components will not be created automatically for Maven publishing from Android Gradle Plugin 8.0. To opt-in to the future behavior, set the Gradle property android.disableAutomaticComponentCreation=true in the 'gradle.properties' file or use the new publishing DSL.

Configure project :maps-api-googlemaps
WARNING: Software Components will not be created automatically for Maven publishing from Android Gradle Plugin 8.0. To opt-in to the future behavior, set the Gradle property android.disableAutomaticComponentCreation=true in the 'gradle.properties' file or use the new publishing DSL.

Configure project :maps-api-openstreetmap
WARNING: Software Components will not be created automatically for Maven publishing from Android Gradle Plugin 8.0. To opt-in to the future behavior, set the Gradle property android.disableAutomaticComponentCreation=true in the 'gradle.properties' file or use the new publishing DSL.

As a result, the build failed. This issue affects the Maven publishing functionality in the Android Gradle Plugin 8.0.

Steps to Reproduce:

1. Create a release on GitHub.
2. Observe the build and publish process for the Maps API.

Expected Behavior: The build process should succeed, and the Maven publishing for the Maps API should complete without any warnings or errors.

Actual Behavior: The build fails with the warning messages mentioned above, indicating that software components are not created automatically for Maven publishing. Consequently, the build cannot proceed.

Additional Information:

• Project repository: [Insert project repository URL]
• Release build details: [Provide information about the release build, such as the branch, commit, or tag used]

GitHub Actions Run Details: Here is the link to the GitHub Actions run that encountered this issue:

I kindly request the project team to investigate this issue and provide necessary guidance or updates regarding the Maven publishing configuration in Android Gradle Plugin 8.0. If possible, please look into the provided GitHub Actions run details for more insights.

Thank you for your attention to this matter. Please let me know if there is any additional information or assistance I can provide.

CC - @prestonlau @rquino

[Anwera64]

The issue isn't with those warning, instead it's an authorization issue. Here in the log it mentions the exception:

• What went wrong: Execution failed for task ':initializeSonatypeStagingRepository'. Failed to create staging repository, server at https://s01.oss.sonatype.org/service/local/ responded with status code 401, body:

Do check that the secrets are correctly set up

[dzuluaga]

Anton, my understanding is that scripts use the repository secrets which have been updated according to what you requested. Could you please take a look at what could be missing? Steps to reproduce are included above. Thanks

[Anwera64]

As I mentioned, the issue here is within the secrets themselves. I do not have access to them, so I'm unable to check that the values are correct

[Anwera64]

I think I know what's the issue here. The names of the secrets should be as the following strings in this snippet:

val ossrhUsername by extra(getValueFromEnvOrProperties("ossrhUsername"))
val ossrhPassword by extra(getValueFromEnvOrProperties("ossrhPassword"))
val mStagingProfileId by extra(getValueFromEnvOrProperties("stagingProfileId"))
val signingKeyId by extra(getValueFromEnvOrProperties("signing.keyId"))
val signingPassword by extra(getValueFromEnvOrProperties("signing.password"))
val signingKey by extra(getValueFromEnvOrProperties("signing.key"))

[dzuluaga]

I appreciate it if you could have mentioned it earlier when I shared the environment variables back in May. Additionally, I would have expected the code to be tested against the naming conventions, as it could have helped us identify any issues. I'll proceed to recreate the secrets. Thank you for your understanding and cooperation.

[dzuluaga]

GitHub secrets converts all variables into uppercase. To resolve this, we need to update the scripts. Can you please help me with this task and test the release scripts in the CD process? Thanks for looking into it.

[Anwera64]

Could you share the latest names for the variables so that we can update them in the script? Thank you

[dzuluaga]

The names remain unchanged. So they're the same as the ones in the screenshot. Thanks!

[Anwera64]

I'm sorry, the previous strings proposed was a confusion on my part with the gradle script. The publishing scripts are setup according to the guide that you provided us with in the same Slack thread. The secret names are configured according to the same guide:

I'd kindly ask of you to update the secrets to the guide's naming conventions to avoid having to update the scripts in the Auth and Maps repositories.

[Anwera64]

Also word of advice, I don't recommend testing the scripts for release if you aren't ready to release yet, because once the repos are uploaded to maven central they will be set in stone.

[dzuluaga]

Thanks, Anton. My understanding is that they get pushed to staging first and manually you push them to release. Right? So, the last step is not done by the scripts. If so, how can only enable the script to push to staging and keep release as a manual step?

[Anwera64]

No, the close and release steps are setup to be done automatically. Else it wouldn't be much of a Continuous Deployment script. I can modify the scripts to only publish to sonatype if you need, but it would be adding a bunch of manual steps for the release process.

[dzuluaga]

Thank you, Anthon, for your comment. I have a question regarding the scripts and publication process. Is there a way we can test the scripts from start to finish, including publishing to staging, and then use a flag or handle the publication manually? Ideally, it would be great if we could have a single manual step, such as signing in to the Nexus Repository Manager and releasing the artifact from staging. Could you please confirm if this is possible? Thank you!

[dzuluaga]

Any news?

[Anwera64]

Yes, that would be possible, but it would require rewritting the publishing scripts and adding some kind of variable, I'm guessing maybe in secrets?

[dzuluaga]

Thanks, Anton. To ensure the scripts are functioning correctly and diagnose the cause of the 401 error from the server, it would be helpful if we could implement the changes discussed. This will allow us to verify their functionality without actually publishing the artifact to the release. Instead, we can keep them in the staging area of Maven Central.

It would indeed be ideal to have badge in the README.md that reflects the successful status of the build. Currently, the badges show a "build failed" status. We should aim to update it to reflect a successful build once we have resolved the issues.

Could you please prioritize looking into this? Your expertise is crucial in resolving this issue. Thank you for your cooperation.

@nelsonwilches - Please incorporate this as part of the requirement. For Storage and Auth. CC - @HectorNarvaez

CC - @rquino @prestonlau

[Anwera64]

this should be resolved with #96

[dzuluaga]

Let me test it.

[Anwera64]

The PR is not merged yet. Take that into account in your tests.

[dzuluaga]

Hi Anthon,

I wanted to let you know that I've retested the release, but unfortunately, I encountered the same 401 error. You can find the details of the test run at this link: GitHub Run.

I noticed that the URL being used is https://s01.oss.sonatype.org/service/local/, and I'm not sure if it's the correct one. Could you please verify it for me? I appreciate your assistance!

Here's the error message I received:

Failed to create staging repository. The server at https://s01.oss.sonatype.org/service/local/ responded with a status code of 401. Body: 

Thank you!

[Anwera64]

As I mentioned before, the change hasn't merged yet, so you won't be able to test it. Please be patient

[Anwera64]

You can test it now @dzuluaga

[dzuluaga]

Please test the code and inform me when you can successfully execute the action, as it still generates 401 errors. Thank you.

[Anwera64]

The action fails because you are running the old version of the script. You can see that by clicking on the workflow file button in the action run summary page and comparing it to the repository version.

[dzuluaga]

They still fail with the latest code. The error is about local.properties' could not be found. I believe you need to set up a step to create this file first see this code from @hans-hamel

Here's the job

Also, the GitHub Actions aren't set up for manually running. Please check this PR to set them up properly.

Could you please run the scripts end-to-end and inform me as soon as they run successfully? Thanks

[Anwera64]

Sure, will do

[Anwera64]

Hey, @dzuluaga the fix has been merged, but the default branch has changed, so we can't test the scripts.

[dzuluaga]

Branch switched to release/1.0. Please test and confirm. Thx

[Anwera64]

You should validate if there's a way to restrict access to the github actions so that only trusted accounts could initialize a worflow by the way.

[Anwera64]

The script works as intented now: https://github.com/openmobilehub/omh-maps/actions/runs/5260524610/jobs/9507539020

Edit:

The implementations have been published succesfuly as well:

https://github.com/openmobilehub/omh-maps/actions/runs/5260573540 https://github.com/openmobilehub/omh-maps/actions/runs/5260572778

[dzuluaga]

I noticed that the Maven central coordinates include an "undefined" part, which doesn't look right. This could will cause some trouble when trying to access these artifacts. Could take a look and fix this issue? Thanks!

[Anwera64]

That's just the description. Check the content to see the correct address.

[dzuluaga]

Anton,

While the Maven central coordinates may be correct, the lack of prominently displayed version information creates a frustrating user experience. It would greatly enhance usability if the version numbers were easily accessible upfront. Please address this issue for future artifact publications.

Thank you for your attention to this matter. Diego

[teban1288]

Ok, since this was something not defined previously, it's good to have a definition on what should be present on the description, from what I understand, we should include in future releases the version number here.

As Diego mentions, please use this as reference for future publications.

[dzuluaga]

Hi Esteban,

Thank you for addressing this matter. I appreciate your intervention. However, I'd like to clarify that including the version number in the description is not a "new" requirement. In fact, if you review the previous artifacts uploaded to Sonatype, you will notice that they have consistently included a more meaningful description, which encompasses the version without the redundant undefined value. Please take a look at the provided snapshot for reference.

Once again, thank you for your understanding and cooperation.

Best, Diego

[Anwera64]

@dzuluaga those descriptions are manually introduced when closing the repository by the person in charge of the operation. We added them just to have some clarity for ourselves when working with the staging area. The uploaded repositories always started with the generic description that's highlighted in red in your screenshot.

I'll take some days off my asigned tasks to look into the documentation and see if it's possible to upload the repository with the requirement you have provided yesterday.

[dzuluaga]

Sounds good. Thanks for looking into it.

Pls.disregard my last message.

[dzuluaga]

To the back burner. Will review CI scripts again to include the version in the description automatically. Description will be updated manually. No further action is required at this point. Please leave this issue open for tracking purposes.

[dzuluaga]

Old issues cleanup.