Opt-out of the analytics call about osio-pipeline

[sbose78]

Edited the description to reflect that the call actually hadn't failed.

[hrishin]

Thanks for reporting it, @sbose78.

How do I opt-out of analytics

At this moment we cant without forking and making changes in it. Though to disable it, one simply need to disable the event hooks or don't register analytics plugin. But not sure giving such a feature is desirable.

A couple of questions:

1. Did it fail the build? (edit: please ignore this question)
2. WDYM by "re-usable, that would be a nice feature to have"? Any specific thing?

[sbose78]

WDYM by "re-usable, that would be a nice feature to have"? Any specific thing?

In case some customer wants to use the the library without the analytics ( which happens on a remote server ), I feel there should be way to turn it off.

[spaparaju]

I am trying to get analytics plugin to be part of upstream Jenkins Image. Till that time, any change at OSIO pipelines would knock out stack report and require discussion with PM team.

[piyush-garg]

@SriKrishnaPaparaju we are not removing the stack report call from pipeline, we are just adding a flag to make it optional only. For the Jenkins file which gets created while creating a booster in OSIO, it will be still there. This is my understanding.

@chmouel Do you have any other thoughts around this?

[chmouel]

That is correct, we are just detecting if the function is available in there, so we can handle those use cases,

[chmouel]

@pgarg following the MM chat conversation

There is two different things here :

• Detect if the plugin is there and fallback gracefully, (i.e: try/expect)

• Allow the user to disable the plugin on their JenkinsFile

As for the syntax on how to disable the plugin in the JenkinsFile, can you past examples on how the syntax would look like?

/cc @sthaha since he own the UX of the jenkinsfile :)

[piyush-garg]

Currently, the jenkinsFile looks like

@Library('github.com/fabric8io/osio-pipeline@master') _

osio {

  config runtime: 'node'

  ci {
      ////
  }

  cd {
      ////
  }

}

But for allowing the user to disable, these two options are in my mind

1. Move config block out of osio block

@Library('github.com/fabric8io/osio-pipeline@master') _

config runtime: 'node' generateStackReport: `true`

osio {

  ci {
      ////
  }

  cd {
      ////
  }

}

2. Keep config Block inside osio but pass flag

@Library('github.com/fabric8io/osio-pipeline@master') _

osio(generateStackReport: true) {

  config runtime: 'node' 

  ci {
      ////
  }

  cd {
      ////
  }

}

Open to other suggestions.

[sthaha]

I see it as one of the configuration of a plugin and could be stored within plugins. Perhaps the library could choose to not register plugins that have their plugins.<name>.disabled set to true (name being `"analytics" in this case).

@Library(...) _

osio {
  config runtime: 'node'    // same no change

  // plugins is a new configuration that is specific to plugins
  plugins analytics: [
        disabled: true   //  false by default
    ]

  plugins foobar: [
        verbosity: "info"   //  understood only by the plugin
        ignore_dirs: "test"
    ]

  ci {
       // .... 
  }

  cd {
     // ...
  }
}

but now the question becomes, how do I disable analytics only for CI ?

[sbose78]

but now the question becomes, how do I disable analytics only for CI ?

Initially, let's only support all or nothing?

[sthaha]

but now the question becomes, how do I disable analytics only for CI ?

Initially, let's only support all or nothing?

The thing about API is that once it is out there, it is difficult to take it back, so while I agree with your comment superficially, it may be better to sketch out how the experience (UX) would be if we were to support disabling the plugin only for CI.

[sbose78]

We could support a global one, and then support a local override. Would that be a problem with registration of plugins if it's disabled at the global level, but enabled locally?

[piyush-garg]

We are registering plugins at the start of osio block, so we even need to move plugins out of osio block like this

@Library(...) _

// plugin is a new configuration that is specific to plugins
plugins analytics: [
    disabled: true   //  false by default
]

plugins foobar: [
    verbosity: "info"   //  understood only by the plugin
    ignore_dirs: "test"
]

osio {

    config runtime: 'node'    // same no change

    ci {
         // .... 
    }

    cd {
        // ...
    }
}

We are registering plugins, before executing the body of osio block and after the start of pipeline/osio block. If we don't do this, we need to move registration of plugins to CI/CD block

[hrishin]

Yeah it makes sense

// plugins is a new configuration that is specific to plugins
  plugins analytics: [
        disabled: true   //  false by default
    ]

Since there could be multiple plugins. Again its YAGNI may be. For the time being its okay to disable all in one go.

plugins all: [
 disable: true
]

[piyush-garg]

Tasks to be done

• Don't call analytics service if the Bayesian plugin is not there
• Provide a configurable option of enabling/disabling a plugin
• Add docs about new configuration api

[sthaha]

@piyush-garg @sbose78 @hrishin just side note...

we could use a alpha/beta/unstable branch where new experimental api can be introduced and can be changed/broken without any notice until it moves to one of the stable branches - master, v1, v1.0 etc ...

This should help us solve bikeshedding and allow us to get a feel for how the feature will be used.

[hrishin]

that's better idea @sthaha !!

[hrishin]

Once we enable sem ver release for pipeline, that will automatically address this issue isn't it?