Re: Discussion: Jenkins Core Maintainer/Developer discussion channels

[Vlad Silverman]

I also think that mattermost is a reasonable chat solution for devops teams 
- https://github.com/mattermost.  Besides results of comparing mattermost 
and slack are pretty obvious - https://mattermost.com/mattermost-vs-slack/
 :-)
Just my 2c

Thx, Vlad

On Wednesday, April 8, 2020 at 5:17:38 AM UTC-7, Oleg Nenashev wrote:
>
> Hi all,
>
> In the Proposal: Expanding the Jenkins Core maintainers team 
> 
>  thread 
> we briefly discussed creation of chats and other communication channels for 
> Jenkins core maintainers which could help in the case of runtime 
> communications: merge/changelog discussions, sync-ups between maintainers, 
> etc. Right now we mostly use pull requests and mailing lists for such kind 
> of discussions, but a number of private messages between maintainers makes 
> me tink that we might be lacking a chat for runtime discussions. Also, we 
> could setup a regular call to discuss maintenance topics, do reviews in the 
> screenshare mode and to do knowledge transfers about the codebase.
>
> I would appreciate feedback from Jenkins core maintainers and active 
> contributors:
>
>- Would a dedicated chat help us? E.g. jenkinsci/core-developers in 
>Gitter
>- Would it make sense to have a regular or an on-demand call for core 
>maintainers? 
>
> Thanks for your time,
> Oleg
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/9d3db873-77b7-4a0c-97e8-82cbd3a413b0%40googlegroups.com.

Re: [jenkins-infra] Jenkins Core Release automation

[Olblak]

Today, during the infra meeting, we discussed creating a new weekly release 
from the new process this Thursday the 16th at 3PM UTC.
While there won't be major features, the purpose of this release is to validate 
that everything is working as expected in a real scenario.


I am proposing the following agenda


* 3PM(UTC), I start the release job and we release directly to the master 
branch and directly on repo.jenkins-ci.org/releases.
Currently the release job take approximatively 1h30


* 4:30PM(UTC), or early if ready, I start the packaging process in order to 
publish artifacts to pkg.jenkins.io
Currently, the packaging job take approximatively 15min to run and I estimate 
the script sync.sh to take 15min to run

* 5PM(UTC), we verify that the release is working correctly.

During the whole all process we'll be on IRC, #jenkins-infra channel

Again feel free to raise any concerns you may have.

Cheers

On Tue, Apr 14, 2020, at 4:44 PM, Oleg Nenashev wrote:
> Thanks a lot to Olivier and all other contributors who invested lots of time 
> to get it done! I am looking forward to finally get it over the line, at 
> least for weeklies.
> 
> FWIW, the Sunday's weekly got delayed (due to Easter). We could make an 
> attempt to cut this release using the new flow without waiting for the next 
> weekly.
> 
> Best regards,
> Oleg
> 
> 
> On Tue, Apr 14, 2020 at 4:32 PM Olblak  wrote:
>> __
>> Hi Everybody,
>> 
>> This project is getting to the end and I am looking for a last round of 
>> reviewers and testers before planning a weekly release with the new process.
>> I opened a pull request (link 
>> ) with instructions 
>> about how to trigger a release but currently, it only covers weekly releases.
>> Our first objective is to successfully release weekly versions from 
>> https://release.ci.jenkins.io, then we'll focus on stable and security 
>> releases.
>> 
>> For security releases, the way I see it:
>> 1) We add two security profile, one for weekly and the second one for the 
>> stable in order to trigger a release from jenkinsci-cert/jenkins:master to 
>> https://repo.jenkins-ci.org/releases/
>> 2) Trigger packaging job(weekly or stable profile), 
>> 3) We manually merge from jenkinsci-cert/jenkins:master to 
>> jenkinsci/jenkins:master
>> 
>> For stable releases:
>> 1) We update the stable 
>>  
>> profile branch to 'stable-', variable JENKINS_GIT_BRANCH)
>> 2) We trigger stable release job
>> 3) We trigger stable packaging job
>> 
>> Another topic that needs clarification is who should be able to trigger a 
>> release from release.ci.jenkins.io and who will trigger the different 
>> releases?
>> 
>> Cheers
>> 

>> --
>>  You received this message because you are subscribed to the Google Groups 
>> "Jenkins Infrastructure" group.
>>  To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkins-infra+unsubscr...@googlegroups.com.
>>  To view this discussion on the web, visit 
>> https://groups.google.com/d/msgid/jenkins-infra/8656f659-17ef-49f3-b265-950488fd9b45%40www.fastmail.com
>>  
>> .
> 

> --
>  You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBfFoN7FYM-gFO8NXixcz6nduoLH_HP6ysEsdRrPEgQcA%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/90698ce9-9e17-4d62-be65-6cd13618ed24%40www.fastmail.com.

Re: How to perform a plugin release to Jenkins Artifact Repository through Continuous Integration?

[Matt Sicker]

Typing "mvn release:{prepare,perform}" into a terminal is about as
automated as pressing the "release" button in CI. You can even press
Ctrl-R in a terminal to find the last time you used the command and
use less keystrokes than it takes to type out ci.jenkins.io.

On Fri, Apr 10, 2020 at 11:12 AM Tim Jacomb  wrote:
>
> There's a proposal for automating plugin release here: 
> https://jenkins.io/jep/221
> Not sure what's needed to get it going though, would be great to get done
>
> Thanks
> Tim
>
> On Fri, 10 Apr 2020 at 16:46, Slide  wrote:
>>
>> Yes, all releases are done manually. There are some ideas floating around to 
>> do the deployment in an automated way, but there are some things to flush 
>> out that haven't been solved yet. It's not a hard process. You run mvn 
>> release:prepare release:perform and follow the prompts.
>>
>> On Fri, Apr 10, 2020 at 8:23 AM Shihaaz Buhary  wrote:
>>>
>>> Is that how all the plugins do the release to Jenkins Artifact Repo - 
>>> manually?
>>>
>>> On Thursday, April 9, 2020 at 8:10:17 PM UTC+5:30, slide wrote:

 buildPlugin just wraps up a bunch of the common stuff for ci.jenkins.io 
 for building and testing plugins for master, PRs and branches. It does not 
 release anything to the update center. You need to do releases manually.

 On Thu, Apr 9, 2020 at 6:42 AM Shihaaz Buhary  wrote:
>
> Hi All,
>
> I know how to do a plugin release manually by executing a few commands as 
> mentioned in the Performing a Plugin Release documentation. I can also 
> see a page for Continuous Integration where it mentions about 
> buildPlugin(configurations: buildPlugin.recommendedConfigurations()). 
> What this method actually does? Does it release the plugin to repo 
> through CI? If not, is there a way that we can achieve both (automate the 
> release) together in the above pages? Because I can see almost all the 
> plugins are using only the above buildPlugin(...) method in their 
> Jenkinsfile. Or am I missing something here? I appreciate your help on 
> this.
>
> Thanks,
> Shihaaz
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkin...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/53933abf-1a36-440a-838b-6defbb733cf2%40googlegroups.com.



 --
 Website: http://earl-of-code.com
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/8015df3b-5a54-4796-9831-d142a892bff6%40googlegroups.com.
>>
>>
>>
>> --
>> Website: http://earl-of-code.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcS4VLhzE4Q95MzBDwapKqSNLivk4Y-KyCWdzK9Jwks%2Bg%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bify1eu%3DFs4F9VPYw_Ai_JBySYGCTvNS%2BJdcx%2BO5yWPYPg%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oyGmNnBV_ggqTNtUuaQLzYr7KBiQBfBEK_zXs8Pnpum0w%40mail.gmail.com.

Re: [jenkins-infra] Jenkins Core Release automation

[Oleg Nenashev]

Thanks a lot to Olivier and all other contributors who invested lots of
time to get it done! I am looking forward to finally get it over the line,
at least for weeklies.

FWIW, the Sunday's weekly got delayed (due to Easter). We could make an
attempt to cut this release using the new flow without waiting for the next
weekly.

Best regards,
Oleg


On Tue, Apr 14, 2020 at 4:32 PM Olblak  wrote:

> Hi Everybody,
>
> This project is getting to the end and I am looking for a last round of
> reviewers and testers before planning a weekly release with the new process.
> I opened a pull request (link
> ) with
> instructions about how to trigger a release but currently, it only covers
> weekly releases.
> Our first objective is to successfully release weekly versions from
> https://release.ci.jenkins.io,  then we'll
> focus on stable and security releases.
>
> For security releases, the way I see it:
> 1) We add two security profile, one for weekly and the second one for the
> stable in order to trigger a release from jenkinsci-cert/jenkins:master  to
> https://repo.jenkins-ci.org/releases/
> 2) Trigger packaging job(weekly or stable profile),
> 3) We manually merge from jenkinsci-cert/jenkins:master to
> jenkinsci/jenkins:master
>
> For stable releases:
> 1) We update the stable
> 
> profile branch to 'stable-', variable JENKINS_GIT_BRANCH)
> 2) We trigger stable release job
> 3) We trigger stable packaging job
>
> Another topic that needs clarification is who should be able to trigger a
> release from release.ci.jenkins.io and who will trigger the different
> releases?
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Infrastructure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkins-infra+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/jenkins-infra/8656f659-17ef-49f3-b265-950488fd9b45%40www.fastmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBfFoN7FYM-gFO8NXixcz6nduoLH_HP6ysEsdRrPEgQcA%40mail.gmail.com.

Jenkins Core Release automation

[Olblak]

Hi Everybody,

This project is getting to the end and I am looking for a last round of 
reviewers and testers before planning a weekly release with the new process.
I opened a pull request (link 
) with instructions 
about how to trigger a release but currently, it only covers weekly releases.
Our first objective is to successfully release weekly versions from 
https://release.ci.jenkins.io, then we'll focus on stable and security releases.

For security releases, the way I see it:
1) We add two security profile, one for weekly and the second one for the 
stable in order to trigger a release from jenkinsci-cert/jenkins:master to 
https://repo.jenkins-ci.org/releases/
2) Trigger packaging job(weekly or stable profile), 
3) We manually merge from jenkinsci-cert/jenkins:master to 
jenkinsci/jenkins:master

For stable releases:
1) We update the stable 
 profile 
branch to 'stable-', variable JENKINS_GIT_BRANCH)
2) We trigger stable release job
3) We trigger stable packaging job

Another topic that needs clarification is who should be able to trigger a 
release from release.ci.jenkins.io and who will trigger the different releases?

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8656f659-17ef-49f3-b265-950488fd9b45%40www.fastmail.com.

Re: Proposal: Windows support policy for Jenkins

[Olblak]

I like Oleg proposition very much as it clarifies the different levels of 
support, and it solves Daniel concerned.
We won't run any tests on deprecated infrastructure like XP. 

On Tue, Apr 14, 2020, at 12:41 PM, Oleg Nenashev wrote:
> Taking the feedback, should we introduce support levels like we do with the 
> browser support policy?
> 
> * Level 1 - full support. We run automated testing for these platforms 
>  - amd64 versions of latest Windows and Windows Server versions, with the 
> latest GA update pack (we will need to specify editions in the final policy)
>  - versions in our soon-to-be-official Docker packages (at the moment: 
> windowsservercore and nanoserver 1809)
> * Level 2 - generally supported. We do not actively test it, but we intend to 
> keep compatibility, and we are happy to accept patches
>  - Windows and Windows Server 64bit versions which are generally supported by 
> MS
> * Level 3 - Best effort - We will consider patches if they do not put Level 
> 1/2 support at risk and if they do not create bug maintenance overhead. 
> Support may have limitations and extra requirements. We do not test 
> compatibility, and we may drop support if there is a need
>  - x86 and other non-amd64 architectures
>  - "exotic" windows versions like Windows Embedded
>  - Preview releases and updates by Microsoft
>  - Windows API emulation systems like Wine or ReactOS
> * Level 4 - Unsupported
>  - Platforms and OS versions which are known to be incompatible or which have 
> severe limitations
> 
> Best regards,
> Oleg
> 
> 
> 
> 
> On Sat, Apr 11, 2020, 02:05 Daniel Beck  wrote:
>> 
>> 
>> > On 10. Apr 2020, at 14:26, Oleg Nenashev  wrote:
>> > 
>> > I know for sure that there are Jenkins users running on Windows XP
>> 
>> That's no reason to enable this insanity.
>> 
>> I would advocate for just going with what's generally supported by 
>> Microsoft: Extended support would be in, "throwing bags of money at 
>> Microsoft" support is out, i.e. Windows 7 would have been unsupported since 
>> January.
>> 
>> This approach would also address the problem of not having to manually keep 
>> the policy up to date. As we've seen with the browser support policy, nobody 
>> will update it.
>> Additionally, this has the benefit of being fairly objective criteria, and 
>> would also save us from having to have this conversation again in two years.
>> 
>> (And TBH I would just ignore Windows Embedded Industry, seems like a lot of 
>> effort for very few users.)
>> 
>> Note also that this doesn't mean that Jenkins on these OSes would 
>> necessarily immediately break. If there's a new enough .NET Framework or 
>> whatever on Windows 7, and there's no reason to go with something newer, 
>> then Windows 7 will just continue to work. But users would know that they 
>> cannot indefinitely rely on it.
>> 
>> Obviously I'm +1 for whatever makes it easier for you to support these 
>> components, even if it's just small steps.
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/jenkinsci-dev/oK8pBCzPPpo/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-dev+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/C643B021-1451-4E76-921B-CD9543BA2C86%40beckweb.net.
> 

> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDBoybSRFz4Lsmo_kynGT-BqknBPK%2BjGS87-tO5hZnnuw%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/dc756e15-a1cf-4a1a-a4bd-5189d37e055b%40www.fastmail.com.

Warn or avoid overriding CLI methods

[Manuel Ramón León Jiménez]

Hello everyone.

I've been working on an issue recently. While trying to call the
*disable-job* CLI method, we receive:

*ERROR: object is not an instance of declaring class*

The root cause is because a plugin has overridden the method:
https://github.com/jenkinsci/multi-branch-project-plugin/blob/master/src/main/java/com/github/mjdetullio/jenkins/plugins/multibranch/TemplateDrivenMultiBranchProject.java#L480

So now, if you try to disable a Freestyle job, it fails because it's
expecting a *TemplateDrivenMultiBranchProject* one.

I open this to have feedback about what is best to do here:

   - Avoid overriding CLI methods
   - Warn about that fact on Jenkins console
   - Warn about that fact on Jenkins CLI commands list page
   - Warn about that fact on the CLI command output directly (may break
   some automations)
   - Others


I filed a ticket, not sure what works better:
https://issues.jenkins-ci.org/browse/JENKINS-61893

Thank you, best regards.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAHHyvkOhbYpGUNmY-SB8eVT7oyUOQKS5yRPPJa5t2JzrFF4ztA%40mail.gmail.com.

Re: Proposal: Windows support policy for Jenkins

[Oleg Nenashev]

Taking the feedback, should we introduce support levels like we do with the
browser support policy?

* Level 1 - full support. We run automated testing for these platforms
  - amd64 versions of latest Windows and Windows Server versions, with the
latest GA update pack (we will need to specify editions in the final policy)
  - versions in our soon-to-be-official Docker packages (at the moment:
windowsservercore and nanoserver 1809)
* Level 2 - generally supported. We do not actively test it, but we intend
to keep compatibility, and we are happy to accept patches
  - Windows and Windows Server 64bit versions which are generally supported
by MS
* Level 3 - Best effort - We will consider patches if they do not put Level
1/2 support at risk and if they do not create bug maintenance overhead.
Support may have limitations and extra requirements. We do not test
compatibility, and we may drop support if there is a need
  - x86 and other non-amd64 architectures
  - "exotic" windows versions like Windows Embedded
  - Preview releases and updates by Microsoft
  - Windows API emulation systems like Wine or ReactOS
* Level 4 - Unsupported
  - Platforms and OS versions which are known to be incompatible or which
have severe limitations

Best regards,
Oleg




On Sat, Apr 11, 2020, 02:05 Daniel Beck  wrote:

>
>
> > On 10. Apr 2020, at 14:26, Oleg Nenashev  wrote:
> >
> > I know for sure that there are Jenkins users running on Windows XP
>
> That's no reason to enable this insanity.
>
> I would advocate for just going with what's generally supported by
> Microsoft: Extended support would be in, "throwing bags of money at
> Microsoft" support is out, i.e. Windows 7 would have been unsupported since
> January.
>
> This approach would also address the problem of not having to manually
> keep the policy up to date. As we've seen with the browser support policy,
> nobody will update it.
> Additionally, this has the benefit of being fairly objective criteria, and
> would also save us from having to have this conversation again in two years.
>
> (And TBH I would just ignore Windows Embedded Industry, seems like a lot
> of effort for very few users.)
>
> Note also that this doesn't mean that Jenkins on these OSes would
> necessarily immediately break. If there's a new enough .NET Framework or
> whatever on Windows 7, and there's no reason to go with something newer,
> then Windows 7 will just continue to work. But users would know that they
> cannot indefinitely rely on it.
>
> Obviously I'm +1 for whatever makes it easier for you to support these
> components, even if it's just small steps.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/oK8pBCzPPpo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/C643B021-1451-4E76-921B-CD9543BA2C86%40beckweb.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDBoybSRFz4Lsmo_kynGT-BqknBPK%2BjGS87-tO5hZnnuw%40mail.gmail.com.

Re: ANN: Agent Docker images renaming on April 12-13

[Daniel Beck]

On Mon, Apr 13, 2020 at 10:52 PM Oleg Nenashev 
wrote:

> My pull request is already built for "ssh-agent", so I will go ahead and
> setup DockerHub builds for this image.
>
If there are strong opinions, we have 1-2 extra days to revisit naming
> before the blogpost is shipped.
>

AFAIUI, ssh-slaves wasn't called "SSH Agents" plugin less because of "SSH
Agent" plugin, but more because of the confusion around "ssh-agent" the
program.

Why does this not apply here?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKGuiJMJ%2B5BCz36-%2B1GL9-wAWWxjBwahsBuE9Hbbd_j6g%40mail.gmail.com.

Re: GHPRB plugin

[Antoine Duprat]

Hi Oleg,

Thank you for your answer, I will follow your advice.

Le sam. 11 avr. 2020 à 22:00, Oleg Nenashev  a
écrit :

> Hi,
>
> Yes, the plugin does not look to be actively developed. But it does not
> seem to be abandoned either. I would suggest pinging maintainers in a pull
> request or Jenkins Jira to clarify the status.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/628908cb-638d-4367-b9a6-542f09c0e7de%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2Bg80zmiiuDTfJO-fVoAB%2BOezkXGsao_YOSjWKN%2BUESKUF7FCA%40mail.gmail.com.

Re: ANN: Agent Docker images renaming on April 12-13

[Oliver Gondža]

I vote for ssh-build-agent as I find it a bit more clear next to 
ssh-agent. The sshd-agent describes what is inside rather than what is 
there for the customer.


On 13/04/2020 22.54, Marky Jackson wrote:

I vote for jenkins/ssh-agent

On Apr 13, 2020, at 1:52 PM, Oleg Nenashev > wrote:


Just to summarize the vote for SSH images:

  * "ssh-agent" - (Tim, Jesse - in PR, Alex, Mark - in Gitter)
  * "ssh-build-agent" - (Daniel, Mark, Tim - in PR, Alex - in PR)
  * "sshd-agent" - (Ivan, Mark, Gavin)

After some consideration, I decided to abstain since I neither use nor 
plan to use this image.
My pull request is already built for "ssh-agent", so I will go ahead 
and setup DockerHub builds for this image.
If there are strong opinions, we have 1-2 extra days to revisit naming 
before the blogpost is shipped.


Best regards,
Oleg


On Monday, April 13, 2020 at 2:04:58 PM UTC+2, Mark Waite wrote:

ssh-build-agents sounds great to me.  +1

On Mon, Apr 13, 2020 at 5:40 AM Tim Jacomb > wrote:

+1

On Mon, 13 Apr 2020 at 11:47, Oleg Nenashev
> wrote:

We did not receive any negative feedback about "SSH Build
Agents" AFAICT. This is also my preference at the moment:
https://github.com/jenkinsci/docker-ssh-slave/pull/50


On Mon, Apr 13, 2020, 12:16 Daniel Beck > wrote:



> On 12. Apr 2020, at 15:59, Oleg Nenashev
> wrote:
>
> Regarding the SSH agent image, will wait till
tomorrow to get more feedback.

The plugin is now called "SSH Build Agents", so it
makes sense to me to call the corresponding image
ssh-build-agent.

In fact, all the labels on
https://hub.docker.com/r/jenkins/ssh-slave
 are
already consistent with that. Any negative feedback on
that since you introduced that?

-- 
You received this message because you are subscribed

to a topic in the Google Groups "Jenkins Developers"
group.
To unsubscribe from this topic, visit

https://groups.google.com/d/topic/jenkinsci-dev/oxD-Hd_7l9k/unsubscribe

.
To unsubscribe from this group and all its topics,
send an email to jenkin...@googlegroups.com .
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/42F47D14-A921-40E8-8F49-8660C9ABDCE5%40beckweb.net

.


-- 
You received this message because you are subscribed to

the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to jenkin...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLB%3DjiicZbY4GbdiKetK0H1rBMPEo%2Bonk_YoXAnm14eQjw%40mail.gmail.com

.


-- 
You received this message because you are subscribed to the

Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to jenkin...@googlegroups.com .
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieyVf79FdwrAtwdQfDYLkMV3YSBvX9BP5j_iKRJUiAszw%40mail.gmail.com

.


--
You received this message because you are subscribed to the Google 
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/bb22bf86-b71b-4627-9d66-d20ecf9bcf33%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google 
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to