Enable / disable Repository?

[David Leangen]

What would be the best way to enable / disable a repository?

I want to enable “development” repositories during local development, but disable them during my CI build to ensure that no “funny stuff” gets released to the wild. The build should fail, and a reasonable way would be to ensure that only “approved” or curated repositories get used during the build.

I did not see any way to enable or disable the Repository itself, so maybe some bnd scripting magic?

An “if” statement that surrounds the repository declaration, maybe?

Or moving the declarations to files (like local-build.bnd, ci-build.bnd) and having a switch that will include the right file with the right repository declaration, maybe?


Since I am quite a n00b at bnd scripting, any suggestions by you experts?


Cheers,
=David

[BJ Hargrave]

In the OSGi build,we do:

-plugin.osgi.nexus: \
    aQute.bnd.repository.maven.provider.MavenBndRepository; \
        snapshotUrl="https://oss.sonatype.org/content/repositories/osgi-snapshots/"; \
        releaseUrl="https://oss.sonatype.org/service/local/staging/deploy/maven2/"; \
        index=${.}/osgi-nexus.mvn; \
        name='OSGiNexus'
-releaserepo.publish: ${env;PUBLISH_REPO}

And the CI build sets the PUBLISH_REPO environment variable to 'OSGiNexus'. (We also have ~/.m2/settings.xml for the CI user account configured with the credentials for the nexus repo). On a developers system, the environment var is not set, so there is no releasing.

You can see a similar example on the OSGi enRoute repo but we use credentials from the environment rather than ~/.m2/settings.xml since the CI system is Travis:
https://github.com/osgi/osgi.enroute/blob/master/cnf/build.bnd#L124
https://github.com/osgi/osgi.enroute/blob/master/.travis.yml#L14-L15
https://github.com/osgi/osgi.enroute/blob/master/.travis.yml#L19-L20

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[David Leangen]

Hi BJ,

Thank you very much. This is very useful information.

What you write below describes the “write” side, but I was also wondering about the “read” side.

During development, I may want to experiment a bit. During that process, I may download or reference some third party bundles, but I would not yet want to integrate them into the CI build, as they are still experimental locally. My thought would be to enable this type of experimental (read) repository locally, but disable it during the CI build.

Any thoughts about that type of use case?

Cheers,

=David

[BJ Hargrave]

My first thought is that you should not be putting experimental things in master branch built by the CI :-)

Experiments are for other branches. When they are no longer experiments, you merge them into master.

[David Leangen]

Ok, fair enough. That is indeed how I have been doing things so far.

My motivation is based on (1) the CD process I am trying to put in place, and (2) a discussion on this list some time ago that related resolution of caps/reqs to repository curation. From that discussion, I have bought into the idea that repositories ought to be very well curated.

My thought so far is to have:

 * A “third party” Maven repo that contains **only** those dependencies actually required and vetted

 * An “in-house” repository for released bundles

 * A “Local” repository for local (and experimental) development.

Experimental bundles, it seems to me, would go into the Local repo, and should also go into an experimental branch exactly as you pointed out.

What I was additionally thinking of doing was enforcing the non-use of Local during the CI build. This could be done either by disabling “Local”, or by somehow ensuring that it is empty (i.e. nothing mistakingly merged into master).

Cheers,

=David