Future of the Jenkins CI

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Future of the Jenkins CI

Selenium - Developers mailing list
Continuing some thoughts started in IRC...

The Jenkins CI is at https://ci.seleniumhq.org:8443/. It runs on Google Cloud Platform, in the same project that owns the Cloud Storage buckets for Selenium releases. A major complaint is that only Googlers have admin rights to the underlying machines, which makes a lot of maintenance tasks impossible without help from one of us.

Is the general feeling that we would like to move everything over the Travis and/or Appveyor in the long run? Are there benefits to doing so other than independence from Google (e.g., less maintenance work upgrading Jenkins and the host machines)?

I would be pretty happy about giving away ownership of the Jenkins build. If sentiment is that we should eventually turn down Jenkins and move to a hosted solution so we don't have to manage our own machines, that would be a perfectly fine way to accomplish that.

Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

Jason.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkwJSiTPo5T0bRyjCQ3WOnkPKVfJiaUvRAkNqWWB4Tg5zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Simon Stewart
Inline

On Wed, May 17, 2017 at 11:44 PM, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
Continuing some thoughts started in IRC...

The Jenkins CI is at https://ci.seleniumhq.org:8443/. It runs on Google Cloud Platform, in the same project that owns the Cloud Storage buckets for Selenium releases. A major complaint is that only Googlers have admin rights to the underlying machines, which makes a lot of maintenance tasks impossible without help from one of us.

Is the general feeling that we would like to move everything over the Travis and/or Appveyor in the long run? Are there benefits to doing so other than independence from Google (e.g., less maintenance work upgrading Jenkins and the host machines)?

I'm a little surprised Travis let us run as many builds as we do on their infrastructure, and I'd hate to rely on their goodwill. Having said that, the Jenkins builds have been widely ignored by almost everyone. I think that there are edge-cases that Jenkins handles way better than Travis (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)
 
I would be pretty happy about giving away ownership of the Jenkins build. If sentiment is that we should eventually turn down Jenkins and move to a hosted solution so we don't have to manage our own machines, that would be a perfectly fine way to accomplish that.

I'd like us to have a think about the matrix of tests we consider adds value, and structure our builds appropriately. The shot-gun approach we have now (a not-terribly-close approximation of N languages * M browsers) gives us coverage, but tends to have some pretty clear seams where things go wrong. 
 
Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

No objections at all, as long as the build summaries and logs are publicly available somehow.

Simon

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYGX-XoRZEw_rxbDwHDUAdaeJ2Avu9x5jV1jTAELAWUrgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <[hidden email]> wrote:
I'm a little surprised Travis let us run as many builds as we do on their infrastructure, and I'd hate to rely on their goodwill. Having said that, the Jenkins builds have been widely ignored by almost everyone. I think that there are edge-cases that Jenkins handles way better than Travis (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)

Theoretically, Sauce should work with Travis, right? But we haven't gone to set that up yet.

How much work has it been to maintain the Travis configuration? There's some background level of maintenance required to keep the Jenkins instances running that, theoretically, we wouldn't have to do on a hosted solution.
 
Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

No objections at all, as long as the build summaries and logs are publicly available somehow.

I'll try to figure out how to make that happen.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkyBaMCRPtBvefkXAq4tBTUTMy8%3Dp_zT2bhADhhCVqRK9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Jonathan Lipps
Hi all,

Sauce + Travis support is a thing. See the docs on Travis's site: https://docs.travis-ci.com/user/sauce-connect/ (particularly the part about the JWT encryption which is necessary for builds to be triggered on PRs). Happy to help troubleshoot if something isn't working on the Sauce side.

Cheers,
Jonathan (I work at Sauce)

On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="uwdYx79vBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">simon.m...@...> wrote:
I'm a little surprised Travis let us run as many builds as we do on their infrastructure, and I'd hate to rely on their goodwill. Having said that, the Jenkins builds have been widely ignored by almost everyone. I think that there are edge-cases that Jenkins handles way better than Travis (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)

Theoretically, Sauce should work with Travis, right? But we haven't gone to set that up yet.

How much work has it been to maintain the Travis configuration? There's some background level of maintenance required to keep the Jenkins instances running that, theoretically, we wouldn't have to do on a hosted solution.
 
Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

No objections at all, as long as the build summaries and logs are publicly available somehow.

I'll try to figure out how to make that happen.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
Sorry I left this thread hanging for a while.

Simon's response about considering the right cross-section of tests to run is interesting and should be considered, but not directly relevant to the decision I'm trying to make, which is whether to continue running this Jenkins instance. Hosting it is a liability, particularly because of Jenkins' security track record and the fact that nobody seems to know any longer how this thing was set up.

Given the current state of the Jenkins build, I am tempted to just delete any build that is currently broken (pretty much all of them). The IE tests haven't passed for over a year, and haven't even been attempted for half a year, which seems like a misconfiguration. It would be better to just get rid of those builds rather than just ignoring them and continuing to pretend that we're going to fix them. Perhaps the one exception would be https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke said is responsible for updating the SeHQ website. That should get fixed or migrated to something more reliable.

I would go so far as to say that the entire Jenkins instance should just be deleted wholesale, and if we're insistent on hosting our own Jenkins rather than using Travis or some other hosted solution, then we can rebuild it. Even if we're concerned about Travis's generosity, I would prefer to just cross that bridge if/when it arrives rather than trying to maintain a parallel CI that is ignored.

On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps <[hidden email]> wrote:
Hi all,

Sauce + Travis support is a thing. See the docs on Travis's site: https://docs.travis-ci.com/user/sauce-connect/ (particularly the part about the JWT encryption which is necessary for builds to be triggered on PRs). Happy to help troubleshoot if something isn't working on the Sauce side.

Cheers,
Jonathan (I work at Sauce)

On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <[hidden email]> wrote:
I'm a little surprised Travis let us run as many builds as we do on their infrastructure, and I'd hate to rely on their goodwill. Having said that, the Jenkins builds have been widely ignored by almost everyone. I think that there are edge-cases that Jenkins handles way better than Travis (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)

Theoretically, Sauce should work with Travis, right? But we haven't gone to set that up yet.

How much work has it been to maintain the Travis configuration? There's some background level of maintenance required to keep the Jenkins instances running that, theoretically, we wouldn't have to do on a hosted solution.
 
Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

No objections at all, as long as the build summaries and logs are publicly available somehow.

I'll try to figure out how to make that happen.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkxZejvQE%3Dt42C87M7w8v1GM1WWc9QU%3DYMT7VxDW3H_8nA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

p0deje
My 2 cents on that is for Travis allowing us to experiment with different operating systems and, when combined with Appveyor, allows us to test on all browsers except Edge for now with zero-to-little maintenance.

For Windows we right now run Ruby tests on IE11 using Appveyor. I don't see why other bindings can't do that as well.

For macOS, SafariDriver is not supported, though I've been experimenting with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari) and hopefully at some point https://github.com/travis-ci/travis-ci/issues/7187 will be resolved.

On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
Sorry I left this thread hanging for a while.

Simon's response about considering the right cross-section of tests to run is interesting and should be considered, but not directly relevant to the decision I'm trying to make, which is whether to continue running this Jenkins instance. Hosting it is a liability, particularly because of Jenkins' security track record and the fact that nobody seems to know any longer how this thing was set up.

Given the current state of the Jenkins build, I am tempted to just delete any build that is currently broken (pretty much all of them). The IE tests haven't passed for over a year, and haven't even been attempted for half a year, which seems like a misconfiguration. It would be better to just get rid of those builds rather than just ignoring them and continuing to pretend that we're going to fix them. Perhaps the one exception would be <a href="https://ci.seleniumhq.org:8443/job/SeleniumHQ/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fci.seleniumhq.org%3A8443%2Fjob%2FSeleniumHQ%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuvRipdQr9h8VS3Wbneie-faC5rA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fci.seleniumhq.org%3A8443%2Fjob%2FSeleniumHQ%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuvRipdQr9h8VS3Wbneie-faC5rA&#39;;return true;">https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke said is responsible for updating the SeHQ website. That should get fixed or migrated to something more reliable.

I would go so far as to say that the entire Jenkins instance should just be deleted wholesale, and if we're insistent on hosting our own Jenkins rather than using Travis or some other hosted solution, then we can rebuild it. Even if we're concerned about Travis's generosity, I would prefer to just cross that bridge if/when it arrives rather than trying to maintain a parallel CI that is ignored.

On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="JxZfFgroAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jli...@...> wrote:
Hi all,

Sauce + Travis support is a thing. See the docs on Travis's site: <a href="https://docs.travis-ci.com/user/sauce-connect/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.travis-ci.com%2Fuser%2Fsauce-connect%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNENrXTmc3A_iFqRJfdyDaCimkyS7A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.travis-ci.com%2Fuser%2Fsauce-connect%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNENrXTmc3A_iFqRJfdyDaCimkyS7A&#39;;return true;">https://docs.travis-ci.com/user/sauce-connect/ (particularly the part about the JWT encryption which is necessary for builds to be triggered on PRs). Happy to help troubleshoot if something isn't working on the Sauce side.

Cheers,
Jonathan (I work at Sauce)

On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <[hidden email]> wrote:
I'm a little surprised Travis let us run as many builds as we do on their infrastructure, and I'd hate to rely on their goodwill. Having said that, the Jenkins builds have been widely ignored by almost everyone. I think that there are edge-cases that Jenkins handles way better than Travis (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)

Theoretically, Sauce should work with Travis, right? But we haven't gone to set that up yet.

How much work has it been to maintain the Travis configuration? There's some background level of maintenance required to keep the Jenkins instances running that, theoretically, we wouldn't have to do on a hosted solution.
 
Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

No objections at all, as long as the build summaries and logs are publicly available somehow.

I'll try to figure out how to make that happen.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="JxZfFgroAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">selenium-developers+unsubscribe@....
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.

For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
Given the discussion here, I think the security liability we incur by hosting our own Jenkins no longer justifies the marginal utility of having it. I will plan to block public access to the Jenkins instance by the end of June, and to thoroughly delete it by the end of July. We can always revive this in the future if other CI services prove not to be sufficient.

We should try to move the existing Windows Java/JS tests to Travis or Appveyor or wherever. But they've been broken on Jenkins for so long that we're already deriving zero value from them, so I won't feel too bad about losing that coverage in the interim.

I think the "SeleniumHQ" is the one build that definitely needs to be migrated somehow. Luke said something about using it to push changes to seleniumhq.org, but I don't really understand how that happens. If anyone knows for sure, LMK and let's figure out a replacement.

Jason.

On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
My 2 cents on that is for Travis allowing us to experiment with different operating systems and, when combined with Appveyor, allows us to test on all browsers except Edge for now with zero-to-little maintenance.

For Windows we right now run Ruby tests on IE11 using Appveyor. I don't see why other bindings can't do that as well.

For macOS, SafariDriver is not supported, though I've been experimenting with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari) and hopefully at some point https://github.com/travis-ci/travis-ci/issues/7187 will be resolved.

On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
Sorry I left this thread hanging for a while.

Simon's response about considering the right cross-section of tests to run is interesting and should be considered, but not directly relevant to the decision I'm trying to make, which is whether to continue running this Jenkins instance. Hosting it is a liability, particularly because of Jenkins' security track record and the fact that nobody seems to know any longer how this thing was set up.

Given the current state of the Jenkins build, I am tempted to just delete any build that is currently broken (pretty much all of them). The IE tests haven't passed for over a year, and haven't even been attempted for half a year, which seems like a misconfiguration. It would be better to just get rid of those builds rather than just ignoring them and continuing to pretend that we're going to fix them. Perhaps the one exception would be https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke said is responsible for updating the SeHQ website. That should get fixed or migrated to something more reliable.

I would go so far as to say that the entire Jenkins instance should just be deleted wholesale, and if we're insistent on hosting our own Jenkins rather than using Travis or some other hosted solution, then we can rebuild it. Even if we're concerned about Travis's generosity, I would prefer to just cross that bridge if/when it arrives rather than trying to maintain a parallel CI that is ignored.

On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps <[hidden email]> wrote:
Hi all,

Sauce + Travis support is a thing. See the docs on Travis's site: https://docs.travis-ci.com/user/sauce-connect/ (particularly the part about the JWT encryption which is necessary for builds to be triggered on PRs). Happy to help troubleshoot if something isn't working on the Sauce side.

Cheers,
Jonathan (I work at Sauce)

On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <[hidden email]> wrote:
I'm a little surprised Travis let us run as many builds as we do on their infrastructure, and I'd hate to rely on their goodwill. Having said that, the Jenkins builds have been widely ignored by almost everyone. I think that there are edge-cases that Jenkins handles way better than Travis (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)

Theoretically, Sauce should work with Travis, right? But we haven't gone to set that up yet.

How much work has it been to maintain the Travis configuration? There's some background level of maintenance required to keep the Jenkins instances running that, theoretically, we wouldn't have to do on a hosted solution.
 
Finally, would there be any objections to limiting access to the Jenkins instance? Given Jenkins' history of security incidents, I would like to limit our exposure a bit, and limiting access to authenticated users -- with access granted very liberally to anyone who asks -- would help. I'd be concerned about making the CI less useful to random Selenium contributors, but then, I'm not sure anybody ever really looks at it anyway.

No objections at all, as long as the build summaries and logs are publicly available somehow.

I'll try to figure out how to make that happen.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscrib[hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkw-JhHAgrb1QZZXv2BdemUs4jkn9U-SKpSaRfkv%3DT%3DKRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Luke Inman-Semerau
We are using google app engine with maven to deploy. We basically
followed the instructions here:

https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp

So, the oauth token is installed on jenkins and that's how it's
working today. The only thing we'd need in another CI solution is to
provide credentials to update the app engine account securely.

On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:

> Given the discussion here, I think the security liability we incur by
> hosting our own Jenkins no longer justifies the marginal utility of having
> it. I will plan to block public access to the Jenkins instance by the end of
> June, and to thoroughly delete it by the end of July. We can always revive
> this in the future if other CI services prove not to be sufficient.
>
> We should try to move the existing Windows Java/JS tests to Travis or
> Appveyor or wherever. But they've been broken on Jenkins for so long that
> we're already deriving zero value from them, so I won't feel too bad about
> losing that coverage in the interim.
>
> I think the "SeleniumHQ" is the one build that definitely needs to be
> migrated somehow. Luke said something about using it to push changes to
> seleniumhq.org, but I don't really understand how that happens. If anyone
> knows for sure, LMK and let's figure out a replacement.
>
> Jason.
>
> On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>>
>> My 2 cents on that is for Travis allowing us to experiment with different
>> operating systems and, when combined with Appveyor, allows us to test on all
>> browsers except Edge for now with zero-to-little maintenance.
>>
>> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> see why other bindings can't do that as well.
>>
>> For macOS, SafariDriver is not supported, though I've been experimenting
>> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari) and
>> hopefully at some point https://github.com/travis-ci/travis-ci/issues/7187
>> will be resolved.
>>
>> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>>>
>>> Sorry I left this thread hanging for a while.
>>>
>>> Simon's response about considering the right cross-section of tests to
>>> run is interesting and should be considered, but not directly relevant to
>>> the decision I'm trying to make, which is whether to continue running this
>>> Jenkins instance. Hosting it is a liability, particularly because of
>>> Jenkins' security track record and the fact that nobody seems to know any
>>> longer how this thing was set up.
>>>
>>> Given the current state of the Jenkins build, I am tempted to just delete
>>> any build that is currently broken (pretty much all of them). The IE tests
>>> haven't passed for over a year, and haven't even been attempted for half a
>>> year, which seems like a misconfiguration. It would be better to just get
>>> rid of those builds rather than just ignoring them and continuing to pretend
>>> that we're going to fix them. Perhaps the one exception would be
>>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke said is
>>> responsible for updating the SeHQ website. That should get fixed or migrated
>>> to something more reliable.
>>>
>>> I would go so far as to say that the entire Jenkins instance should just
>>> be deleted wholesale, and if we're insistent on hosting our own Jenkins
>>> rather than using Travis or some other hosted solution, then we can rebuild
>>> it. Even if we're concerned about Travis's generosity, I would prefer to
>>> just cross that bridge if/when it arrives rather than trying to maintain a
>>> parallel CI that is ignored.
>>>
>>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps <[hidden email]>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part about
>>>> the JWT encryption which is necessary for builds to be triggered on PRs).
>>>> Happy to help troubleshoot if something isn't working on the Sauce side.
>>>>
>>>> Cheers,
>>>> Jonathan (I work at Sauce)
>>>>
>>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>>>>>
>>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> I'm a little surprised Travis let us run as many builds as we do on
>>>>>> their infrastructure, and I'd hate to rely on their goodwill. Having said
>>>>>> that, the Jenkins builds have been widely ignored by almost everyone. I
>>>>>> think that there are edge-cases that Jenkins handles way better than Travis
>>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)
>>>>>
>>>>>
>>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>>>>> gone to set that up yet.
>>>>>
>>>>> How much work has it been to maintain the Travis configuration? There's
>>>>> some background level of maintenance required to keep the Jenkins instances
>>>>> running that, theoretically, we wouldn't have to do on a hosted solution.
>>>>>
>>>>>>>
>>>>>>> Finally, would there be any objections to limiting access to the
>>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I would like
>>>>>>> to limit our exposure a bit, and limiting access to authenticated users --
>>>>>>> with access granted very liberally to anyone who asks -- would help. I'd be
>>>>>>> concerned about making the CI less useful to random Selenium contributors,
>>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>>>>>>
>>>>>>
>>>>>> No objections at all, as long as the build summaries and logs are
>>>>>> publicly available somehow.
>>>>>
>>>>>
>>>>> I'll try to figure out how to make that happen.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Selenium Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [hidden email].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Selenium Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAL97Zu6dvTZ%3DpUq2v_%3DLOQ-Opy0GRXOqTzVXydDQgveE%3Dw1ToQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
I see. It doesn't really make sense for us to put that on something like Travis, then -- we're certainly not going to put your OAuth token in the codebase. Maybe we can rig up something lightweight in our existing GCP project to do that deployment.

On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]> wrote:
We are using google app engine with maven to deploy. We basically
followed the instructions here:

https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp

So, the oauth token is installed on jenkins and that's how it's
working today. The only thing we'd need in another CI solution is to
provide credentials to update the app engine account securely.

On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
> Given the discussion here, I think the security liability we incur by
> hosting our own Jenkins no longer justifies the marginal utility of having
> it. I will plan to block public access to the Jenkins instance by the end of
> June, and to thoroughly delete it by the end of July. We can always revive
> this in the future if other CI services prove not to be sufficient.
>
> We should try to move the existing Windows Java/JS tests to Travis or
> Appveyor or wherever. But they've been broken on Jenkins for so long that
> we're already deriving zero value from them, so I won't feel too bad about
> losing that coverage in the interim.
>
> I think the "SeleniumHQ" is the one build that definitely needs to be
> migrated somehow. Luke said something about using it to push changes to
> seleniumhq.org, but I don't really understand how that happens. If anyone
> knows for sure, LMK and let's figure out a replacement.
>
> Jason.
>
> On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>>
>> My 2 cents on that is for Travis allowing us to experiment with different
>> operating systems and, when combined with Appveyor, allows us to test on all
>> browsers except Edge for now with zero-to-little maintenance.
>>
>> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> see why other bindings can't do that as well.
>>
>> For macOS, SafariDriver is not supported, though I've been experimenting
>> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari) and
>> hopefully at some point https://github.com/travis-ci/travis-ci/issues/7187
>> will be resolved.
>>
>> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>>>
>>> Sorry I left this thread hanging for a while.
>>>
>>> Simon's response about considering the right cross-section of tests to
>>> run is interesting and should be considered, but not directly relevant to
>>> the decision I'm trying to make, which is whether to continue running this
>>> Jenkins instance. Hosting it is a liability, particularly because of
>>> Jenkins' security track record and the fact that nobody seems to know any
>>> longer how this thing was set up.
>>>
>>> Given the current state of the Jenkins build, I am tempted to just delete
>>> any build that is currently broken (pretty much all of them). The IE tests
>>> haven't passed for over a year, and haven't even been attempted for half a
>>> year, which seems like a misconfiguration. It would be better to just get
>>> rid of those builds rather than just ignoring them and continuing to pretend
>>> that we're going to fix them. Perhaps the one exception would be
>>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke said is
>>> responsible for updating the SeHQ website. That should get fixed or migrated
>>> to something more reliable.
>>>
>>> I would go so far as to say that the entire Jenkins instance should just
>>> be deleted wholesale, and if we're insistent on hosting our own Jenkins
>>> rather than using Travis or some other hosted solution, then we can rebuild
>>> it. Even if we're concerned about Travis's generosity, I would prefer to
>>> just cross that bridge if/when it arrives rather than trying to maintain a
>>> parallel CI that is ignored.
>>>
>>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps <[hidden email]>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part about
>>>> the JWT encryption which is necessary for builds to be triggered on PRs).
>>>> Happy to help troubleshoot if something isn't working on the Sauce side.
>>>>
>>>> Cheers,
>>>> Jonathan (I work at Sauce)
>>>>
>>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>>>>>
>>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> I'm a little surprised Travis let us run as many builds as we do on
>>>>>> their infrastructure, and I'd hate to rely on their goodwill. Having said
>>>>>> that, the Jenkins builds have been widely ignored by almost everyone. I
>>>>>> think that there are edge-cases that Jenkins handles way better than Travis
>>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than I do)
>>>>>
>>>>>
>>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>>>>> gone to set that up yet.
>>>>>
>>>>> How much work has it been to maintain the Travis configuration? There's
>>>>> some background level of maintenance required to keep the Jenkins instances
>>>>> running that, theoretically, we wouldn't have to do on a hosted solution.
>>>>>
>>>>>>>
>>>>>>> Finally, would there be any objections to limiting access to the
>>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I would like
>>>>>>> to limit our exposure a bit, and limiting access to authenticated users --
>>>>>>> with access granted very liberally to anyone who asks -- would help. I'd be
>>>>>>> concerned about making the CI less useful to random Selenium contributors,
>>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>>>>>>
>>>>>>
>>>>>> No objections at all, as long as the build summaries and logs are
>>>>>> publicly available somehow.
>>>>>
>>>>>
>>>>> I'll try to figure out how to make that happen.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Selenium Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [hidden email].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Selenium Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkzpdUcKqAy5wef6it_M6hG6wXODFesD_MUGzNgiDKh7iQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Luke Inman-Semerau
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:

> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAL97Zu4ntgme6Yij1tjD8BvtB1cAMHo6bwMvZLYx5KwM8zYoPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
Oh, that looks perfect. I'll plan to look into that later in the week, then.

On Mon, Jun 19, 2017 at 10:24 PM, Luke Inman-Semerau <[hidden email]> wrote:
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:
> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkzCqaEEhT%2BJsmiUMYNxSkZeL2uDTBhRhVYV5VR%2BRdUWjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
This is working now.

I've shut down the Jenkins VMs. We still have the disk images if there's anything there that needs to be recovered for some reason. Luke, you can invalidate your old OAuth token if you want.

On Mon, Jun 19, 2017 at 10:36 PM, Jason Juang <[hidden email]> wrote:
Oh, that looks perfect. I'll plan to look into that later in the week, then.

On Mon, Jun 19, 2017 at 10:24 PM, Luke Inman-Semerau <[hidden email]> wrote:
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:
> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>


--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkwPN_PDogx73EDJh8aAW-fD9zvc-%3D%3D4vQ%3DD_Sdgi6pfhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Simon Stewart
Thank you, Jason. I guess our next step is try and update the website and see what breaks :)

Simon

On Fri, Jun 30, 2017 at 2:51 AM, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
This is working now.

I've shut down the Jenkins VMs. We still have the disk images if there's anything there that needs to be recovered for some reason. Luke, you can invalidate your old OAuth token if you want.

On Mon, Jun 19, 2017 at 10:36 PM, Jason Juang <[hidden email]> wrote:
Oh, that looks perfect. I'll plan to look into that later in the week, then.

On Mon, Jun 19, 2017 at 10:24 PM, Luke Inman-Semerau <[hidden email]> wrote:
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:
> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>


--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkwPN_PDogx73EDJh8aAW-fD9zvc-%3D%3D4vQ%3DD_Sdgi6pfhQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYFO3KO1cs9VfZrd_4Bb7pQ%2BS1E1XVGO1syWMrDADiQTpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Selenium - Developers mailing list
FWIW, I did already do a couple deploys from Travis -- I made a token change to the website just to make sure it got pushed, and it did. (I even got an email to tell me the build passed.)

By the way, I found credentials for an [hidden email] user in the Jenkins config. I actually used that account to go in to the GAE project and set up service account permissions for Travis. Is that user used for anything else? If not, it should be removed, or at least we should change the password, so that not every Googler with source access can go much with sehq.org.

On Fri, Jun 30, 2017 at 3:20 AM, Simon Stewart <[hidden email]> wrote:
Thank you, Jason. I guess our next step is try and update the website and see what breaks :)

Simon

On Fri, Jun 30, 2017 at 2:51 AM, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
This is working now.

I've shut down the Jenkins VMs. We still have the disk images if there's anything there that needs to be recovered for some reason. Luke, you can invalidate your old OAuth token if you want.

On Mon, Jun 19, 2017 at 10:36 PM, Jason Juang <[hidden email]> wrote:
Oh, that looks perfect. I'll plan to look into that later in the week, then.

On Mon, Jun 19, 2017 at 10:24 PM, Luke Inman-Semerau <[hidden email]> wrote:
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:
> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>


--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkwPN_PDogx73EDJh8aAW-fD9zvc-%3D%3D4vQ%3DD_Sdgi6pfhQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYFO3KO1cs9VfZrd_4Bb7pQ%2BS1E1XVGO1syWMrDADiQTpA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkxZqzR0OLU%3DNzKEXEG31xFGoYeBg7q3O1C2E9LvxJ%2B%3DhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Daniel Wagner-Hall
On 1 July 2017 at 01:01, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
FWIW, I did already do a couple deploys from Travis -- I made a token change to the website just to make sure it got pushed, and it did. (I even got an email to tell me the build passed.)

Sounds awesome! Thanks for tearing this stuff down so cleanly :)

By the way, I found credentials for an [hidden email] user in the Jenkins config. I actually used that account to go in to the GAE project and set up service account permissions for Travis. Is that user used for anything else? If not, it should be removed, or at least we should change the password, so that not every Googler with source access can go much with sehq.org.

As far as I know, that's the only thing it's used for. That said, I'm not aware of how releases are pushed to Google Cloud Storage.
 

On Fri, Jun 30, 2017 at 3:20 AM, Simon Stewart <[hidden email]> wrote:
Thank you, Jason. I guess our next step is try and update the website and see what breaks :)

Simon

On Fri, Jun 30, 2017 at 2:51 AM, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
This is working now.

I've shut down the Jenkins VMs. We still have the disk images if there's anything there that needs to be recovered for some reason. Luke, you can invalidate your old OAuth token if you want.

On Mon, Jun 19, 2017 at 10:36 PM, Jason Juang <[hidden email]> wrote:
Oh, that looks perfect. I'll plan to look into that later in the week, then.

On Mon, Jun 19, 2017 at 10:24 PM, Luke Inman-Semerau <[hidden email]> wrote:
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:
> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>


--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkwPN_PDogx73EDJh8aAW-fD9zvc-%3D%3D4vQ%3DD_Sdgi6pfhQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYFO3KO1cs9VfZrd_4Bb7pQ%2BS1E1XVGO1syWMrDADiQTpA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkxZqzR0OLU%3DNzKEXEG31xFGoYeBg7q3O1C2E9LvxJ%2B%3DhA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CA%2Bc80B%2BO6Zd2uuAf%2BS%3DxuQOeD1suNMo6vLb7ssWVLa3uzknVUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Future of the Jenkins CI

Simon Stewart
On Sat, Jul 1, 2017 at 7:59 PM, Daniel Wagner-Hall <[hidden email]> wrote:
On 1 July 2017 at 01:01, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
FWIW, I did already do a couple deploys from Travis -- I made a token change to the website just to make sure it got pushed, and it did. (I even got an email to tell me the build passed.)

Sounds awesome! Thanks for tearing this stuff down so cleanly :)

+1
 
By the way, I found credentials for an [hidden email] user in the Jenkins config. I actually used that account to go in to the GAE project and set up service account permissions for Travis. Is that user used for anything else? If not, it should be removed, or at least we should change the password, so that not every Googler with source access can go much with sehq.org.

As far as I know, that's the only thing it's used for. That said, I'm not aware of how releases are pushed to Google Cloud Storage.


Which is called from the `:push_release` target.

Simon
 
 

On Fri, Jun 30, 2017 at 3:20 AM, Simon Stewart <[hidden email]> wrote:
Thank you, Jason. I guess our next step is try and update the website and see what breaks :)

Simon

On Fri, Jun 30, 2017 at 2:51 AM, 'Jason Juang' via Selenium Developers <[hidden email]> wrote:
This is working now.

I've shut down the Jenkins VMs. We still have the disk images if there's anything there that needs to be recovered for some reason. Luke, you can invalidate your old OAuth token if you want.

On Mon, Jun 19, 2017 at 10:36 PM, Jason Juang <[hidden email]> wrote:
Oh, that looks perfect. I'll plan to look into that later in the week, then.

On Mon, Jun 19, 2017 at 10:24 PM, Luke Inman-Semerau <[hidden email]> wrote:
Travis-ci does have a way to encrypt secrets in the yaml file -
https://docs.travis-ci.com/user/encryption-keys/

Which we could do.

On Mon, Jun 19, 2017 at 10:09 PM, Jason Juang <[hidden email]> wrote:
> I see. It doesn't really make sense for us to put that on something like
> Travis, then -- we're certainly not going to put your OAuth token in the
> codebase. Maybe we can rig up something lightweight in our existing GCP
> project to do that deployment.
>
> On Mon, Jun 19, 2017 at 7:28 PM, Luke Inman-Semerau <[hidden email]>
> wrote:
>>
>> We are using google app engine with maven to deploy. We basically
>> followed the instructions here:
>>
>> https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
>>
>> So, the oauth token is installed on jenkins and that's how it's
>> working today. The only thing we'd need in another CI solution is to
>> provide credentials to update the app engine account securely.
>>
>> On Mon, Jun 19, 2017 at 6:14 PM, Jason Juang <[hidden email]> wrote:
>> > Given the discussion here, I think the security liability we incur by
>> > hosting our own Jenkins no longer justifies the marginal utility of
>> > having
>> > it. I will plan to block public access to the Jenkins instance by the
>> > end of
>> > June, and to thoroughly delete it by the end of July. We can always
>> > revive
>> > this in the future if other CI services prove not to be sufficient.
>> >
>> > We should try to move the existing Windows Java/JS tests to Travis or
>> > Appveyor or wherever. But they've been broken on Jenkins for so long
>> > that
>> > we're already deriving zero value from them, so I won't feel too bad
>> > about
>> > losing that coverage in the interim.
>> >
>> > I think the "SeleniumHQ" is the one build that definitely needs to be
>> > migrated somehow. Luke said something about using it to push changes to
>> > seleniumhq.org, but I don't really understand how that happens. If
>> > anyone
>> > knows for sure, LMK and let's figure out a replacement.
>> >
>> > Jason.
>> >
>> > On Tue, Jun 13, 2017 at 7:08 AM, Alex Rodionov <[hidden email]> wrote:
>> >>
>> >> My 2 cents on that is for Travis allowing us to experiment with
>> >> different
>> >> operating systems and, when combined with Appveyor, allows us to test
>> >> on all
>> >> browsers except Edge for now with zero-to-little maintenance.
>> >>
>> >> For Windows we right now run Ruby tests on IE11 using Appveyor. I don't
>> >> see why other bindings can't do that as well.
>> >>
>> >> For macOS, SafariDriver is not supported, though I've been
>> >> experimenting
>> >> with it (see https://github.com/SeleniumHQ/selenium/tree/travis-safari)
>> >> and
>> >> hopefully at some point
>> >> https://github.com/travis-ci/travis-ci/issues/7187
>> >> will be resolved.
>> >>
>> >> On Tuesday, June 13, 2017 at 8:02:36 AM UTC+6, Jason Juang wrote:
>> >>>
>> >>> Sorry I left this thread hanging for a while.
>> >>>
>> >>> Simon's response about considering the right cross-section of tests to
>> >>> run is interesting and should be considered, but not directly relevant
>> >>> to
>> >>> the decision I'm trying to make, which is whether to continue running
>> >>> this
>> >>> Jenkins instance. Hosting it is a liability, particularly because of
>> >>> Jenkins' security track record and the fact that nobody seems to know
>> >>> any
>> >>> longer how this thing was set up.
>> >>>
>> >>> Given the current state of the Jenkins build, I am tempted to just
>> >>> delete
>> >>> any build that is currently broken (pretty much all of them). The IE
>> >>> tests
>> >>> haven't passed for over a year, and haven't even been attempted for
>> >>> half a
>> >>> year, which seems like a misconfiguration. It would be better to just
>> >>> get
>> >>> rid of those builds rather than just ignoring them and continuing to
>> >>> pretend
>> >>> that we're going to fix them. Perhaps the one exception would be
>> >>> https://ci.seleniumhq.org:8443/job/SeleniumHQ/, which I think Luke
>> >>> said is
>> >>> responsible for updating the SeHQ website. That should get fixed or
>> >>> migrated
>> >>> to something more reliable.
>> >>>
>> >>> I would go so far as to say that the entire Jenkins instance should
>> >>> just
>> >>> be deleted wholesale, and if we're insistent on hosting our own
>> >>> Jenkins
>> >>> rather than using Travis or some other hosted solution, then we can
>> >>> rebuild
>> >>> it. Even if we're concerned about Travis's generosity, I would prefer
>> >>> to
>> >>> just cross that bridge if/when it arrives rather than trying to
>> >>> maintain a
>> >>> parallel CI that is ignored.
>> >>>
>> >>> On Mon, May 22, 2017 at 10:20 AM, Jonathan Lipps
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Sauce + Travis support is a thing. See the docs on Travis's site:
>> >>>> https://docs.travis-ci.com/user/sauce-connect/ (particularly the part
>> >>>> about
>> >>>> the JWT encryption which is necessary for builds to be triggered on
>> >>>> PRs).
>> >>>> Happy to help troubleshoot if something isn't working on the Sauce
>> >>>> side.
>> >>>>
>> >>>> Cheers,
>> >>>> Jonathan (I work at Sauce)
>> >>>>
>> >>>> On Friday, May 19, 2017 at 8:50:41 PM UTC-7, Jason Juang wrote:
>> >>>>>
>> >>>>> On Thu, May 18, 2017 at 2:27 AM, Simon Stewart
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> I'm a little surprised Travis let us run as many builds as we do on
>> >>>>>> their infrastructure, and I'd hate to rely on their goodwill.
>> >>>>>> Having said
>> >>>>>> that, the Jenkins builds have been widely ignored by almost
>> >>>>>> everyone. I
>> >>>>>> think that there are edge-cases that Jenkins handles way better
>> >>>>>> than Travis
>> >>>>>> (the Sauce stuff, perhaps --- Luke and Daniel would know more than
>> >>>>>> I do)
>> >>>>>
>> >>>>>
>> >>>>> Theoretically, Sauce should work with Travis, right? But we haven't
>> >>>>> gone to set that up yet.
>> >>>>>
>> >>>>> How much work has it been to maintain the Travis configuration?
>> >>>>> There's
>> >>>>> some background level of maintenance required to keep the Jenkins
>> >>>>> instances
>> >>>>> running that, theoretically, we wouldn't have to do on a hosted
>> >>>>> solution.
>> >>>>>
>> >>>>>>>
>> >>>>>>> Finally, would there be any objections to limiting access to the
>> >>>>>>> Jenkins instance? Given Jenkins' history of security incidents, I
>> >>>>>>> would like
>> >>>>>>> to limit our exposure a bit, and limiting access to authenticated
>> >>>>>>> users --
>> >>>>>>> with access granted very liberally to anyone who asks -- would
>> >>>>>>> help. I'd be
>> >>>>>>> concerned about making the CI less useful to random Selenium
>> >>>>>>> contributors,
>> >>>>>>> but then, I'm not sure anybody ever really looks at it anyway.
>> >>>>>>
>> >>>>>>
>> >>>>>> No objections at all, as long as the build summaries and logs are
>> >>>>>> publicly available somehow.
>> >>>>>
>> >>>>>
>> >>>>> I'll try to figure out how to make that happen.
>> >>>>
>> >>>> --
>> >>>> You received this message because you are subscribed to the Google
>> >>>> Groups "Selenium Developers" group.
>> >>>> To unsubscribe from this group and stop receiving emails from it,
>> >>>> send
>> >>>> an email to [hidden email].
>> >>>> To view this discussion on the web visit
>> >>>>
>> >>>> https://groups.google.com/d/msgid/selenium-developers/602840d6-3293-4ab5-b431-1ccff1e91122%40googlegroups.com.
>> >>>>
>> >>>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Selenium Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to [hidden email].
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/selenium-developers/be44da67-4848-4f17-bc10-9d65a7d38994%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>


--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkwPN_PDogx73EDJh8aAW-fD9zvc-%3D%3D4vQ%3DD_Sdgi6pfhQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYFO3KO1cs9VfZrd_4Bb7pQ%2BS1E1XVGO1syWMrDADiQTpA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAN_hBkxZqzR0OLU%3DNzKEXEG31xFGoYeBg7q3O1C2E9LvxJ%2B%3DhA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CA%2Bc80B%2BO6Zd2uuAf%2BS%3DxuQOeD1suNMo6vLb7ssWVLa3uzknVUQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYHk13SQ%2BBnSoukxegvaSshs3mjeVQRsWSgUhBqAP%2BsegQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.