it can be discussed on the infra list in...@lists.jenkins-ci.org and if
everyone is agree it could be changed.
I agree that I don't really see the interest of using default assignees in
Jira (I always found this counter productive)
On Mon, Sep 5, 2016 at 6:35 PM, Craig Rodrigues
Arnaud,
Thanks for fixing this. How can I put a proposal to the Jenkins admins
that if a ticket is filed with Project* Infrastructure*, Component *CI* that
it gets assigned to a group of people, and not a single person?
I'm not able to attend the weekly Jenkins governance meetings.
Due to the
INFRA-741 fixed. But I agree that it is better to not assign them.
Also our community CI should evolve soon with our recent partnership with
Azure : https://jenkins.io/blog/2016/05/18/announcing-azure-partnership/
On Thu, Aug 4, 2016 at 9:15 AM, Craig Rodrigues wrote:
> I'm
I'm OK with Cloudbees using a template to lock things down for
jenkins.io.cloudbees.com.
One thing I would suggest is that in JIRA, if someone files an issue at
https://issues.jenkins-ci.org
in Project *Infrastructure*, Component: *ci*, instead of auto-assigning the
issue to one
person (rtyler),
Yup +1. I can relate. This property has been existing for years and we used
it quite a lot.
Cheers
Le 22 juil. 2016 6:24 PM, "Thomas Zoratto" a
écrit :
> The doc was only updated one week ago.
>
> As Arnaud pointed out, this property is available for a long time I
The doc was only updated one week ago.
As Arnaud pointed out, this property is available for a long time I think. You
can find a reference about it in a old 2009 article
(http://www.sonarqube.org/using-quality-profiles-in-sonar/)
> Le 22 juil. 2016 à 16:54, Kanstantsin Shautsou
I think it exists for a long time, I used it in my previous company to
manage quality indicators accross several development baselines/branches
On Fri, Jul 22, 2016 at 4:54 PM, Kanstantsin Shautsou <
kanstantsin@gmail.com> wrote:
> Thanks, will look. Doc appeared one week ago?
>
> On
Thanks, will look. Doc appeared one week ago?
On Friday, July 22, 2016 at 2:46:44 PM UTC+3, Thomas Zoratto wrote:
>
> I’m not sure if this is what you mean by 'missing stats per branche' or
> not but you can have different reports for each branch in SonarQube (see
> sonar.branch property
>
I’m not sure if this is what you mean by 'missing stats per branche' or not but
you can have different reports for each branch in SonarQube (see sonar.branch
property http://docs.sonarqube.org/display/SONAR/Analysis+Parameters)
> Le 22 juil. 2016 à 00:27, Kanstantsin Shautsou
Good question, AFAIR we discussed few times to have SonarQube and Coverity
specially for Jenkins, but end with unability to do something in INFRA.
According to email answer, public sonarqube (nemo instance?) has no “service”
feature where people can manage themselves configuration.
Codecov.io is
codecov is a competitor of SonarQube ?
ex : https://sonarqube.com/overview?id=org.jenkins-ci.main%3Apom
On Thu, Jul 21, 2016 at 8:18 PM, Gavin Mogan wrote:
> I asked the same question late last year.
>
> I have heard rumors that the cloudbees templates are being updated
I asked the same question late last year.
I have heard rumors that the cloudbees templates are being updated to use
Jenkinsfile, which would be awesome.
Right now we've forked and done development on our own repo so we can
trigger a build that does codecov and a few other minor things, but it
> On Jul 21, 2016, at 02:14, Kohsuke Kawaguchi wrote:
>
> Jenkins does provide a way to configure the build process, for example via
> Jenkinsfile, via Job DSL plugin, etc.
Thanks, i know.
>
> Like I said in my previous email, it's just that in jenkins.io.cloudbees.com
>
Jenkins does provide a way to configure the build process, for example via
Jenkinsfile, via Job DSL plugin, etc.
Like I said in my previous email, it's just that in jenkins.io.cloudbees.com
we choose to use a template to lock things down.
IIUC reviewable.io is orthogonal to this. That's between
Jenkins CloudBees doesn’t provide any ways to control or configure build
process and integrations. In 2016 that’s blocker for development. Also you
can’t do anything with reviewable.io because you have no analogues.
> On Jul 20, 2016, at 23:51, Kohsuke Kawaguchi wrote:
>
>
So in this case the motivation is to activate Codecov.io on plugins. On
https://jenkins.ci.cloudbees.com/job/plugins/ we use templating so that we
only need to change the setting once to impact every plugin.
If we make that change across the board, would that make you happy enough
to stop the use
Ability to configure build process, ability to set credentials and upload
something to external services, etc.
> On Jul 16, 2016, at 00:35, Liam Newman wrote:
>
> Andrey,
> What does running in TravisCI provide that is not already in the
> jenkinsci.org build? Just
Andrey,
What does running in TravisCI provide that is not already in the
jenkinsci.org build? Just wondering.
Thanks!
Liam Newman
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails
Done.
> On 06.07.2016, at 11:12, Andrey Pohilko wrote:
>
> Can anybody help me enabling it?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Try contact INFRA team and ask them to provide admin access to your plugin.
On Wednesday, July 6, 2016 at 12:12:07 PM UTC+3, Andrey Pohilko wrote:
>
> Hi,
>
> I'm the maintainer for performance-plugin repo.
>
> I'm trying to use my typical approach with controlling the project quality
> using
Hi,
I'm the maintainer for performance-plugin repo.
I'm trying to use my typical approach with controlling the project quality
using GitHub+TravisCI+Codecov integration, which proven its value for me.
However, I'm missing the admin right on repo to enable TravisCI for it. Can
anybody help me
21 matches
Mail list logo