-
Notifications
You must be signed in to change notification settings - Fork 751
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
Provide an option to by pass generating a settings.xml file #79
Comments
I'd say that ideally, the default should be not to generate |
If that is possible, sure. I assume there is an existing use case internally that conflicts with this. I think the cases where it can safely generate a setting.xml are:
|
Hello everyone!
|
I am still at loss as to why the action deals with Maven at all. Why should installing java involve anything with Maven? |
@maxim-lobanov could you please share again the reasoning behind the Maven specific functionality? |
I don't have much historical context but @konradpabjan has shared some details in #132 (comment)
|
I will also add that support was expanded not just for Github package registry (you can publish to any Maven Central Repository). See this guide: https://docs.github.com/en/actions/guides/publishing-java-packages-with-gradle
Without the Maven logic in |
My concern with this thinking is that it opens the door to add a lot of other features. More importantly, how is this impacted by a build that uses a matrix of multiple Java versions? Will settings.xml be updated every time for each version? What if I want to publish 2+ times, to different locations (e.g. private repo, public repo, staging repo)? |
This concern is fair enough and we definitely need to be very selective for new features in future. |
When using self-hosted runners we provision compute with a Maven
settings.xml
and currently this action will overwrite our correctsettings.xml
with one that's inoperable. It would be nice to signal to the action to not generate asettings.xml
file.Another option might be to allow a template
.github/workflow/maven/settings.xml
that can be provisioned on the runner. In the case of running with GitHub actions proper the template can use${{ secrets.references }}
and in self-host just normal envars which Maven will interpolate into the settings file. Either way it's secure.The text was updated successfully, but these errors were encountered: