default the namespace for the openshift plugin operations when we're executing in a pipeline that has a namespace associated about jenkins-plugin HOT 10 CLOSED

I've found BuildCause.java in the openshift-sync code and am working on a patch to pull that from the Run object and update the namespace if it is present. I'd rather call BuildCause.getNamespace() vs. parsing the short description that is available with the base hudson Cause class, so I'm first trying to make openshift-sync a dependency for openshift-pipeline (which will test my still young maven/pom skills :-) as the typical way I've created dependencies is not working at the moment ). Later on, if we are worried about size or circular dependencies, switching to parsing the short description is always a fallback option.

The order of precedence I'm envisioning is:

1. if customer explicitly sets the namespace, go with that
2. if sync plugin sets i cause, go with that
3. go with the two existing default mechanisms (PROJECT_NAME env or namespace file mounted in the Pod

from jenkins-plugin.

got the maven dependency working :-)

from jenkins-plugin.

1. if customer explicitly sets the namespace, go with that

sets it in the build step or sets it in the global plugin settings (if that's even a thing they can do)?

from jenkins-plugin.

On Wed, Jul 27, 2016 at 4:44 PM, Ben Parees [email protected]
wrote:

1. if customer explicitly sets the namespace, go with that

sets it in the build step or sets it in the global plugin settings (if
that's even a thing they can do)?

Both in effect. The user puts some sort of value in any of our steps
fields, but that value could be an env var
that is defined either at the job level or the global level.

2. if sync plugin sets i cause, go with that
3. go with the two existing default mechanisms (PROJECT_NAME env or
   namespace file mounted in the Pod

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#54 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbadJzkGcHcZge-f8QZC7n6GfJ5DkQ3ks5qZ8MugaJpZM4JVdu1
.

from jenkins-plugin.

Both in effect. The user puts some sort of value in any of our steps fields

ok but there's no way to define a global default value (not env variable) that the steps will use?

from jenkins-plugin.

Not currently, since to date pulling the default from what is mounted in the pod has been acceptable. But if isolating the project jenkins runs in from the "app" project has grown enough, we can special case the namespace and give it that means in addition to the env var stuff.

from jenkins-plugin.

fine for now, just wanted to make sure the full precedence hierarchy was represented. your proposal sounds good to me.

from jenkins-plugin.

ok cool @bparees

@siamaksade - I have pushed a pre-release change for the openshift pipeline plugin that should have it pull the namespace/project from the cause that the sync plugin sets before pulling it from what is mounted in the pod.

Download this binary and upgrade the plugin being used by your jenkins install via the Manage Jenkins -> Manage Plugins path if you want to give it a try.

from jenkins-plugin.

I'll give it a try and come back to you today

from jenkins-plugin.

For the record, it worked as expected

from jenkins-plugin.