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

Add configurations to use internal Nexus repository #810

Open
mh11 opened this issue May 30, 2022 · 6 comments
Open

Add configurations to use internal Nexus repository #810

mh11 opened this issue May 30, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@mh11
Copy link

mh11 commented May 30, 2022

Is your feature request related to a problem? Please describe.
Building of new projects fail due to missing repository configuration.

Describe the solution you'd like
Adding the required configurations to the project would provide a solid foundation and consistency across projects.
e.g. A Java project using gradle requires the correct Nexus URL for code dependencies ( in build.gradle) and managing plugins (in settings.gradle)

Describe alternatives you've considered
An alternative is to allow the firewall to connect to all public repositories

Additional context
none

Example settings.gradle settings:

pluginManagement {
    repositories {
        maven {
            url "https://nexus-repository-url.some.where/repository/maven-central/"
        }
        maven {
            url "https://nexus-repository-url.some.where/repository/atlassian_public/"
        }
        maven {
            url "https://nexus-repository-url.some.where/repository/maven-public/"
        }
    }
}
rootProject.name = 'my-amazing-project'
@mh11 mh11 added the enhancement New feature or request label May 30, 2022
@metmajer
Copy link
Member

Thank you @mh11. @braisvq1996 we will need to use the repositories only if USE_NEXUS is enabled, I assume. @jafarre-viewnext can you advise?

@metmajer metmajer added this to To Do in ODS Maintenance via automation May 30, 2022
@braisvq1996
Copy link
Contributor

braisvq1996 commented May 30, 2022

We already have something similar for build.gradle here and check if we have nexus here, we could follow a similar approach

@mh11
Copy link
Author

mh11 commented May 30, 2022

If I read this correctly, that works for a controlled environment (e.g. Jenkins).
I think, that you can't assume, that the user has all the variables set correctly in their environment.
It would be good that the configuration file is generated with the URLs set, when the project is provisioned (or read from a properties file) - all contained within the project.

@metmajer
Copy link
Member

@mh11 environment variables are a widely-used way of configuring an application, and proposed as part of the 12-factor apps approach. When using the EDP, this environment variable is automatically set. When using the component on a local machine, you need to set this by hand or as part of your .bashrc file (or similar).

@mh11
Copy link
Author

mh11 commented May 31, 2022

I know that the "hard-coded" URLs would interfere with EDP and would violate the 12-factor apps approach. But the ultimate question is, how to enable / support the user to get started with an enviroment, which could range from "nothing" to "multiple" configurations. In addition - what are the default resources a user should use (public vs internal).
One way to leaverage environment variables are to overwrite a default behaviour by providing alternative settings. In this case, you might want to (i) set the Nexus URLs hardcoded (not nice, I know) as default pointing at the internally Nexus and (ii) "disabled" or overwrite them, when a variable e.g. EDP_CONTROLED or NO_NEXUS exists.

@renedupont
Copy link
Member

For gradle, you can add a gradle.properties with the nexus settings of your ocp cluster to your local .gradle folder and it will be picked up by gradle for any gradle execution of any project you might provision afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

No branches or pull requests

4 participants