Comments (18)
Edited the description to reflect that the call actually hadn't failed.
from osio-pipeline.
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:
- Did it fail the build? (edit: please ignore this question)
- WDYM by "re-usable, that would be a nice feature to have"? Any specific thing?
from osio-pipeline.
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.
from osio-pipeline.
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.
from osio-pipeline.
@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?
from osio-pipeline.
That is correct, we are just detecting if the function is available in there, so we can handle those use cases,
from osio-pipeline.
@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 :)
from osio-pipeline.
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
- Move
config
block out ofosio
block
@Library('github.com/fabric8io/osio-pipeline@master') _
config runtime: 'node' generateStackReport: `true`
osio {
ci {
////
}
cd {
////
}
}
- Keep
config
Block insideosio
but pass flag
@Library('github.com/fabric8io/osio-pipeline@master') _
osio(generateStackReport: true) {
config runtime: 'node'
ci {
////
}
cd {
////
}
}
Open to other suggestions.
from osio-pipeline.
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 ?
from osio-pipeline.
but now the question becomes, how do I disable analytics only for CI ?
Initially, let's only support all or nothing?
from osio-pipeline.
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.
from osio-pipeline.
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?
from osio-pipeline.
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
from osio-pipeline.
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
]
from osio-pipeline.
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
from osio-pipeline.
@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.
from osio-pipeline.
that's better idea @sthaha !!
from osio-pipeline.
Once we enable sem ver release for pipeline, that will automatically address this issue isn't it?
from osio-pipeline.
Related Issues (20)
- Image promotion between environment HOT 5
- Multi environments support HOT 2
- Rename OSIO-Pipeline codeready toolchain based name
- Add a diagram of osio-pipeline flow
- oc new-app integration HOT 7
- update doc for the config API
- Add golang slave image support in pipeline HOT 2
- Add debug/verbose mode
- Private GIT repo
- Split application.yaml between build and deploy bits HOT 1
- Attach a secret to an environment HOT 1
- refactor the pipeline code
- update Readme for runTest, testNamespace and changes in spawn API HOT 1
- Pipeline build API is failing
- Verify Deployment is not waiting for pod to be ready HOT 1
- Go Based OSIO-Pipeline - Proposal
- revert runtest API related changes
- make this library independent of osio constraints HOT 1
- Documentation for jenkinsfile-runners
- Detect if bayeseian plugin is available HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osio-pipeline.