configure Jenkins to test PRs #169

Closed
garfieldnate opened this Issue Jul 18, 2014 · 10 comments

Comments

Projects
None yet
3 participants
@garfieldnate
Contributor

garfieldnate commented Jul 18, 2014

It would be nice if you could know if a PR is going to break the build or not before you merge it, without having to test it manually (so you don't have to reverse later like with e8a5a4d). Jenkins can test PR's for you using this plugin (installation screenshots here). There are also other tools Jently and Jennifer, if those are preferred.

@bluechill

This comment has been minimized.

Show comment
Hide comment
@bluechill

bluechill Jul 18, 2014

Member

I had tried this earlier but it didn't work. However after reading the instructions for the new version, i think I know how to get it to work. I'll look into this today.

Alex

On Jul 18, 2014, at 4:34 AM, garfieldnate notifications@github.com wrote:

It would be nice if you could know if a PR is going to break the build or not before you merge it, without having to test it manually (so you don't have to reverse later like with e8a5a4d). Jenkins can test PR's for you using this plugin (installation screenshots here). There are also other tools Jently and Jennifer, if those are preferred.


Reply to this email directly or view it on GitHub.

Member

bluechill commented Jul 18, 2014

I had tried this earlier but it didn't work. However after reading the instructions for the new version, i think I know how to get it to work. I'll look into this today.

Alex

On Jul 18, 2014, at 4:34 AM, garfieldnate notifications@github.com wrote:

It would be nice if you could know if a PR is going to break the build or not before you merge it, without having to test it manually (so you don't have to reverse later like with e8a5a4d). Jenkins can test PR's for you using this plugin (installation screenshots here). There are also other tools Jently and Jennifer, if those are preferred.


Reply to this email directly or view it on GitHub.

@bluechill

This comment has been minimized.

Show comment
Hide comment
@bluechill

bluechill Jul 18, 2014

Member

This has been added. By the way, you should now have the ability to read our jobs (along with other users not a member of SoarGroup).

Member

bluechill commented Jul 18, 2014

This has been added. By the way, you should now have the ability to read our jobs (along with other users not a member of SoarGroup).

@bluechill bluechill closed this Jul 18, 2014

@garfieldnate

This comment has been minimized.

Show comment
Hide comment
@garfieldnate

garfieldnate Jul 18, 2014

Contributor

Thank you! This will be an invaluable tool. Will the Soar Group get emailed when a PR build failed? I think it would be better not to have that so that a PR can be updated several times without spamming the list.

Contributor

garfieldnate commented Jul 18, 2014

Thank you! This will be an invaluable tool. Will the Soar Group get emailed when a PR build failed? I think it would be better not to have that so that a PR can be updated several times without spamming the list.

@bluechill

This comment has been minimized.

Show comment
Hide comment
@bluechill

bluechill Jul 18, 2014

Member

Only me, Mazin, and Bazald get updated when it breaks (along with who broke it).

Alex

On Jul 18, 2014, at 10:55 AM, garfieldnate notifications@github.com wrote:

Thank you! This will be an invaluable tool. Will the Soar Group get emailed when a PR build failed? I think it would be better not to have that so that a PR can be updated several times without spamming the list.


Reply to this email directly or view it on GitHub.

Member

bluechill commented Jul 18, 2014

Only me, Mazin, and Bazald get updated when it breaks (along with who broke it).

Alex

On Jul 18, 2014, at 10:55 AM, garfieldnate notifications@github.com wrote:

Thank you! This will be an invaluable tool. Will the Soar Group get emailed when a PR build failed? I think it would be better not to have that so that a PR can be updated several times without spamming the list.


Reply to this email directly or view it on GitHub.

@mazina

This comment has been minimized.

Show comment
Hide comment
@mazina

mazina Jul 18, 2014

Contributor

If this is purely for people to test their personal work before they
propose a merge (if they decide to at all), I'd say limit it to the person
who made the failed commit. I think people would use that feature much
more liberally for testing if they knew it e-mailed nobody but themselves.
I know I would.

On Fri, Jul 18, 2014 at 3:02 PM, Alex T. notifications@github.com wrote:

Only me, Mazin, and Bazald get updated when it breaks (along with who
broke it).

Alex

On Jul 18, 2014, at 10:55 AM, garfieldnate notifications@github.com
wrote:

Thank you! This will be an invaluable tool. Will the Soar Group get
emailed when a PR build failed? I think it would be better not to have that
so that a PR can be updated several times without spamming the list.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#169 (comment).

Contributor

mazina commented Jul 18, 2014

If this is purely for people to test their personal work before they
propose a merge (if they decide to at all), I'd say limit it to the person
who made the failed commit. I think people would use that feature much
more liberally for testing if they knew it e-mailed nobody but themselves.
I know I would.

On Fri, Jul 18, 2014 at 3:02 PM, Alex T. notifications@github.com wrote:

Only me, Mazin, and Bazald get updated when it breaks (along with who
broke it).

Alex

On Jul 18, 2014, at 10:55 AM, garfieldnate notifications@github.com
wrote:

Thank you! This will be an invaluable tool. Will the Soar Group get
emailed when a PR build failed? I think it would be better not to have that
so that a PR can be updated several times without spamming the list.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#169 (comment).

@bluechill

This comment has been minimized.

Show comment
Hide comment
@bluechill

bluechill Jul 18, 2014

Member

Whenever a person makes a pull request, it will build it on Jenkins. This isn't for testing personal work, it's for making sure that before WE merge it in, that it builds after the merge. If it doesn't build then I want to know so I don't merge it in. Also, I want to know because if Jenkins breaks then I can fix it. Basically I think it's best to leave it as is. If you don't want yourself on the email list, then you can remove yourself but I personally think it's useful to have us on there since we're the ones who are probably going to be merging in the pull requests.

Member

bluechill commented Jul 18, 2014

Whenever a person makes a pull request, it will build it on Jenkins. This isn't for testing personal work, it's for making sure that before WE merge it in, that it builds after the merge. If it doesn't build then I want to know so I don't merge it in. Also, I want to know because if Jenkins breaks then I can fix it. Basically I think it's best to leave it as is. If you don't want yourself on the email list, then you can remove yourself but I personally think it's useful to have us on there since we're the ones who are probably going to be merging in the pull requests.

@mazina

This comment has been minimized.

Show comment
Hide comment
@mazina

mazina Jul 18, 2014

Contributor

I see your point. I was looking at it more like the developmental build
job that we have set up for the experimental branches.

And, since we'll get an e-mail from the pull request itself, getting rid of
those e-mails won't let people work any more silently. (Does the pull
request e-mail have any build success information in it, now that you've
added this plug-in?)

On Fri, Jul 18, 2014 at 4:41 PM, Alex T. notifications@github.com wrote:

Whenever a person makes a pull request, it will build it on Jenkins. This
isn't for testing personal work, it's for making sure that before WE merge
it in, that it builds after the merge. If it doesn't build then I want to
know so I don't merge it in. Also, I want to know because if Jenkins breaks
then I can fix it. Basically I think it's best to leave it as is. If you
don't want yourself on the email list, then you can remove yourself but I
personally think it's useful to have us on there since we're the ones who
are probably going to be merging in the pull requests.


Reply to this email directly or view it on GitHub
#169 (comment).

Contributor

mazina commented Jul 18, 2014

I see your point. I was looking at it more like the developmental build
job that we have set up for the experimental branches.

And, since we'll get an e-mail from the pull request itself, getting rid of
those e-mails won't let people work any more silently. (Does the pull
request e-mail have any build success information in it, now that you've
added this plug-in?)

On Fri, Jul 18, 2014 at 4:41 PM, Alex T. notifications@github.com wrote:

Whenever a person makes a pull request, it will build it on Jenkins. This
isn't for testing personal work, it's for making sure that before WE merge
it in, that it builds after the merge. If it doesn't build then I want to
know so I don't merge it in. Also, I want to know because if Jenkins breaks
then I can fix it. Basically I think it's best to leave it as is. If you
don't want yourself on the email list, then you can remove yourself but I
personally think it's useful to have us on there since we're the ones who
are probably going to be merging in the pull requests.


Reply to this email directly or view it on GitHub
#169 (comment).

@bluechill

This comment has been minimized.

Show comment
Hide comment
@bluechill

bluechill Jul 18, 2014

Member

No, only on Github will it have that information. It will let you know while it’s building it and when it’s done (whether it’s failed or succeeded) but never send out an email other than Jenkins’.

On Jul 18, 2014, at 5:12 PM, Mazin Assanie notifications@github.com wrote:

I see your point. I was looking at it more like the developmental build
job that we have set up for the experimental branches.

And, since we'll get an e-mail from the pull request itself, getting rid of
those e-mails won't let people work any more silently. (Does the pull
request e-mail have any build success information in it, now that you've
added this plug-in?)

On Fri, Jul 18, 2014 at 4:41 PM, Alex T. notifications@github.com wrote:

Whenever a person makes a pull request, it will build it on Jenkins. This
isn't for testing personal work, it's for making sure that before WE merge
it in, that it builds after the merge. If it doesn't build then I want to
know so I don't merge it in. Also, I want to know because if Jenkins breaks
then I can fix it. Basically I think it's best to leave it as is. If you
don't want yourself on the email list, then you can remove yourself but I
personally think it's useful to have us on there since we're the ones who
are probably going to be merging in the pull requests.


Reply to this email directly or view it on GitHub
#169 (comment).


Reply to this email directly or view it on GitHub.

Member

bluechill commented Jul 18, 2014

No, only on Github will it have that information. It will let you know while it’s building it and when it’s done (whether it’s failed or succeeded) but never send out an email other than Jenkins’.

On Jul 18, 2014, at 5:12 PM, Mazin Assanie notifications@github.com wrote:

I see your point. I was looking at it more like the developmental build
job that we have set up for the experimental branches.

And, since we'll get an e-mail from the pull request itself, getting rid of
those e-mails won't let people work any more silently. (Does the pull
request e-mail have any build success information in it, now that you've
added this plug-in?)

On Fri, Jul 18, 2014 at 4:41 PM, Alex T. notifications@github.com wrote:

Whenever a person makes a pull request, it will build it on Jenkins. This
isn't for testing personal work, it's for making sure that before WE merge
it in, that it builds after the merge. If it doesn't build then I want to
know so I don't merge it in. Also, I want to know because if Jenkins breaks
then I can fix it. Basically I think it's best to leave it as is. If you
don't want yourself on the email list, then you can remove yourself but I
personally think it's useful to have us on there since we're the ones who
are probably going to be merging in the pull requests.


Reply to this email directly or view it on GitHub
#169 (comment).


Reply to this email directly or view it on GitHub.

@mazina

This comment has been minimized.

Show comment
Hide comment
@mazina

mazina Jul 18, 2014

Contributor

If there's no dev privacy benefit, I'm ambivalent. Like you said, the
build status does is displayed on github when you follow the pull merge
link, but I guess the e-mail could tell me so I don't have to check.

On Fri, Jul 18, 2014 at 5:13 PM, Alex T. notifications@github.com wrote:

No, only on Github will it have that information. It will let you know
while it’s building it and when it’s done (whether it’s failed or
succeeded) but never send out an email other than Jenkins’.

On Jul 18, 2014, at 5:12 PM, Mazin Assanie notifications@github.com
wrote:

I see your point. I was looking at it more like the developmental build
job that we have set up for the experimental branches.

And, since we'll get an e-mail from the pull request itself, getting rid
of
those e-mails won't let people work any more silently. (Does the pull
request e-mail have any build success information in it, now that you've
added this plug-in?)

On Fri, Jul 18, 2014 at 4:41 PM, Alex T. notifications@github.com
wrote:

Whenever a person makes a pull request, it will build it on Jenkins.
This
isn't for testing personal work, it's for making sure that before WE
merge
it in, that it builds after the merge. If it doesn't build then I want
to
know so I don't merge it in. Also, I want to know because if Jenkins
breaks
then I can fix it. Basically I think it's best to leave it as is. If
you
don't want yourself on the email list, then you can remove yourself
but I
personally think it's useful to have us on there since we're the ones
who
are probably going to be merging in the pull requests.


Reply to this email directly or view it on GitHub
#169 (comment).


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#169 (comment).

Contributor

mazina commented Jul 18, 2014

If there's no dev privacy benefit, I'm ambivalent. Like you said, the
build status does is displayed on github when you follow the pull merge
link, but I guess the e-mail could tell me so I don't have to check.

On Fri, Jul 18, 2014 at 5:13 PM, Alex T. notifications@github.com wrote:

No, only on Github will it have that information. It will let you know
while it’s building it and when it’s done (whether it’s failed or
succeeded) but never send out an email other than Jenkins’.

On Jul 18, 2014, at 5:12 PM, Mazin Assanie notifications@github.com
wrote:

I see your point. I was looking at it more like the developmental build
job that we have set up for the experimental branches.

And, since we'll get an e-mail from the pull request itself, getting rid
of
those e-mails won't let people work any more silently. (Does the pull
request e-mail have any build success information in it, now that you've
added this plug-in?)

On Fri, Jul 18, 2014 at 4:41 PM, Alex T. notifications@github.com
wrote:

Whenever a person makes a pull request, it will build it on Jenkins.
This
isn't for testing personal work, it's for making sure that before WE
merge
it in, that it builds after the merge. If it doesn't build then I want
to
know so I don't merge it in. Also, I want to know because if Jenkins
breaks
then I can fix it. Basically I think it's best to leave it as is. If
you
don't want yourself on the email list, then you can remove yourself
but I
personally think it's useful to have us on there since we're the ones
who
are probably going to be merging in the pull requests.


Reply to this email directly or view it on GitHub
#169 (comment).


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#169 (comment).

@garfieldnate

This comment has been minimized.

Show comment
Hide comment
@garfieldnate

garfieldnate Aug 12, 2014

Contributor

#175 was passing in PR tests but failed when actually merged into master. Does the configuration for this need to be revisited?

Contributor

garfieldnate commented Aug 12, 2014

#175 was passing in PR tests but failed when actually merged into master. Does the configuration for this need to be revisited?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment