Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upAdding a module to allow organizations to track usage of Jenkins within their domain #1301
Conversation
…in their domain. There is a privacy concern in having this information reported, but OTOH in a corporate network this seems like a reasonable compromise, and people really often do not have any clues where they are running.
cloudbees-pull-request-builder
commented
Jun 27, 2014
|
core » jenkins-core #950 FAILURE |
|
Maybe add a System property option to disable it to be safe? Or would that defeat the purpose? I mean, I could just block this in the firewall if I wanted… |
Adding a module to allow organizations to track usage of Jenkins within their domain
This comment has been minimized.
This comment has been minimized.
|
What jira issues explains this request? |
|
Why PR that has no approved signs and has |
|
Where is @reviewbybees ? |
The PR description explains it.
Presumably because it's small, has tests, and sat here for 18 months without objections?
It didn't exist when this PR was created. But it wouldn't have hurt to use it anyway, I guess. The feature has been documented (and I added a few more details to the wiki page), but I do agree with Daniel that — like the other Jenkins discovery mechanisms — it should also have a system property feature flag. A changelog entry would also be helpful. |
|
|
|
@orrc @kohsuke is cloudbees employee (right?) and should use @reviewbybees like all other employees because it was already discussed that CB has rule for doing reviews for all their changes?
@orrc by this logic many PRs should be merged even if they are bad.
cc @stephenc ;) |
|
@KostyaSha for the Nth time. At least all the employees that joined CloudBees up to and including my joining date have a very clear delineation between work done for the company and work done for your own enjoyment. (You'd need to ask newer employees what the current wording is though... Mine is very clear and specific) As such, when "off the clock" we are not required to use the reviewed by bees handle... In any case, the whole use of reviewed by bees is an internal policy we have chosen for ourselves. We do not ask anyone to police our internal policies. We could keep the internal reviews private, but we believe that there is a reasonable likelihood of at least a third of our internal reviews either addressing comments that others would ask, or otherwise explain our thinking... Additionally, if a proposed change is completely unwanted, we want maintainers to be able to reject early, rather than having to reject a fully polished unwanted change that has undergone extensive review already. Now whether the Jenkins community's code review team should have been given an chance to review before merging us a completely different - and in my view - much more legitimate question. |
|
@stephenc no idea to what else i can appeal to. Could you provide any technical comments about this change?
IMHO such PR decreases jenkins QA. |
|
@KostyaSha I will repeat what I said earlier
|
|
I see no technical reason not to merge this functionality. I have technical concerns about the initial implementation of the functionality I would prefer to see this discovery mediated by DNS SVR records rather than a "magic" hostname of But that is more an issue with the existing module implementation and not an issue with enabling the feature per-se |
|
@stephenc Thanks for answer. Why people can't install this plugin separately and it should be in default war? |
a plugin is opt-in rather than opt-out. For the use case where @kohsuke has targeted this opt-in is not suitable; think a large big faceless corp, where random devs are spinning up new instances in random labs (in different network segments) - and these random devs wouldn't install this plugin - they probably don't even know it exists - so the reporting fails to fulfill the needs). That said in 2.0 we are secure out of the box (JENKINS-30749) so I think @kzantow needs to disable this feature by default :) |
|
OK, so the follow-up changes are to switch to SRV record and then add a system property to disable this. @jtnord explains well the targeted situation this feature is for, and I've never managed to sell DNS multicast as a solution; people who deal with Jenkins in those big companies aren't network experts, and they are unlikely to have a leverage to influence routing of the entire corporate internal network. Adding DNS entry is something much more routine and easier. |
The root problem was missing <scope>test</scope> in domain-discovery.
|
Reverted this PR since it was uncompilable. Could be redone more carefully and pushed to the same branch to reopen. |
|
FWIW, I really like @stephenc's suggestion:
This would give me "as a sysadmin" a lot more control over this and hell if I can get a a full URL in that SRV record I could just have this ping an existing inventory service without much trouble. |
kohsuke commentedJun 27, 2014
There is a privacy concern in having this information reported, but OTOH in a corporate network this seems like a reasonable compromise, and people really often do not have any clues where they are running.