1. Toc
  2. Topics

CI/CD for Hyperledger projects

Ry Jones
 

Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

Nikolay Yushkevich <nikolai@...>
 

Hi Ry!

In HL Iroha we also heavily use Jenkins. We would love to contribute to the process, I cc’ed our DevOps engineers to the thread.

Nikolai

Project manager at Soramitsu

On 23 Jan 2019, at 22:37, Ry Jones <rjones@...> wrote:

Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

Ry Jones
 

Nikolai,
Great. I look forward to working with you to make Hyperledger's Jenkins useful to the broader community.
Ry


On Wed, Jan 23, 2019 at 11:45 AM Iushkevich Nikolai <nikolai@...> wrote:
Hi Ry!

In HL Iroha we also heavily use Jenkins. We would love to contribute to the process, I cc’ed our DevOps engineers to the thread.

Nikolai


--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

Jonathan Levi (HACERA)
 

Hi everybody,

This is really great - thanks.

1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 

Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.

2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.

Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.

We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.

However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.

In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.

I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.


Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?


I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?

Thanks, 

Jonathan Levi
HACERA  -  To Blockchain with Confidence

Unbounded  To Network with Networks

M  +1.650.686.9029








On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry



Jonathan Levi (HACERA)
 

Adding the HL Fabric team, in case there are new issues that I was not aware of.


Jonathan Levi
HACERA  -  To Blockchain with Confidence


On Thu, Jan 24, 2019, 12:41 AM Jonathan Levi (HACERA) <jonathan@... wrote:
Hi everybody,

This is really great - thanks.

1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 

Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.

2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.

Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.

We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.

However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.

In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.

I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.


Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?


I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?

Thanks, 

Jonathan Levi
HACERA  -  To Blockchain with Confidence

Unbounded  To Network with Networks

M  +1.650.686.9029








On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.

I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.

I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry



Christopher B Ferris <chrisfer@...>
 

Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 

----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

 

 


 
 

Jonathan Levi (HACERA)
 

Thanks Chris,

>> Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT.

^^^ I agree and I used to believe that this was indeed the case.

I see. Didn't realize the Fabric maintainers are/were being asked to move away from Jenkins. What's the problem/issue with our Jenkins?

Thanks, Jonathan


On Thu, Jan 24, 2019, 1:17 AM Christopher B Ferris <chrisfer@... wrote:
Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 
----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

 

 


 
 

Christopher B Ferris <chrisfer@...>
 

not away from Jenkins, but away from use of Jenkins pipelines. We are currently in the process of transitioning from using JJBs to pipelines. JJB are specific configs to jenkins, where as pipelines are specified in the repo under CI.
 
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 

----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Christopher B Ferris <chrisfer@...>
Cc: Ry Jones <rjones@...>, sbonewald@..., Hyperledger List <tsc@...>, hyperledger-fabric <hyperledger-fabric@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 6:26 PM
 
Thanks Chris,
 
>> Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT.
 
^^^ I agree and I used to believe that this was indeed the case.
 
I see. Didn't realize the Fabric maintainers are/were being asked to move away from Jenkins. What's the problem/issue with our Jenkins?
 
Thanks, Jonathan
 
 
On Thu, Jan 24, 2019, 1:17 AM Christopher B Ferris <chrisfer@... wrote:
Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 
----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

 

 


 
 
 

Nikolay Yushkevich <nikolai@...>
 

+1. We definitely need to be in charge of pipeline settings, as it is in our interests to provide a reasonable quality gate for the project.

Nikolai

24 янв. 2019 г., в 2:25, Jonathan Levi (HACERA) <jonathan@...> написал(а):

Thanks Chris,

>> Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT.

^^^ I agree and I used to believe that this was indeed the case.

I see. Didn't realize the Fabric maintainers are/were being asked to move away from Jenkins. What's the problem/issue with our Jenkins?

Thanks, Jonathan


On Thu, Jan 24, 2019, 1:17 AM Christopher B Ferris <chrisfer@... wrote:
Reading the linked note from Ry, it seems that this has little to do with CI/CD and more to do with LFIT process and policies.
  • Opaque process for adding new projects to Jenkins
  • Opaque process for getting changes approved
  • Responsiveness to helpdesk tickets is not good
None of the above is relevant to CI/CD tooling.
 
Now, that said, I also heard that there was pushback from LFIT on Fabric's use of Jenkins pipelines (we would like to move away from the opaque, Rube Goldbergian JJB). Seems to me that the process for a build should be in the control of the project's maintainers, not LFIT. LFIT should be responsible for providing robust and resilient tools and endeavoring to ensure their availability.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
 
 
----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
To: Ry Jones <rjones@...>
Cc: Hyperledger List <tsc@...>, Silona Bonewald <sbonewald@...>
Subject: Re: [Hyperledger TSC] CI/CD for Hyperledger projects
Date: Wed, Jan 23, 2019 5:41 PM
 
Hi everybody,
 
This is really great - thanks.
 
1. Just to confirm, the issues with the Fabric CI/CD were resolved (at least the stuff I have expressed in the quotes thread, well before the latest HL Fabric 1.4 was complete). 
 
Those who followed may have noticed how smooth was Fabric's 1.4-LTS release.... we were even ready a bit ahead of the release and had plenty of time, this time round.
 
2. I keep reading, hearing and am being asked occasionally about the CI/CD, Jenkins, etc
.... but you know, back in the day, we kept the requirements very open, in terms of what tools a project uses. CI/CD is one of such tools/frameworks.
 
Specifically, In Fabric, we managed to get to a much more stable build process over the years. And to be clear, it is mostly thanks to the hard work of Ramesh, the Fabric CI team, and others who helped along the way.
 
We had many issues with versioning, depencies (that are/can be an issue in Golang), Gossip optimizations that used to vary at times from a time to time - and the "ninjas" from the CI/CD team kept on improving things. I am sure they felt that we (the developers and the maintainers) are driving them crazy, but they kept on working hard to address a very long list of issues, as these popped-up.
 
However/but, and this is a big but - I think that it is important to remember that nobody is forcing or pushing anyone to use one CI/CD software or tool vs. another.
 
In a way, we have so much blood and swear invested in stabilizing our process in Fabric... but by all means, don't let our choice affect your choice of tooling... Iroha, Ursa or any other project should be free to work with the platform adm tooling of choice.
 
I can tell you that internally, HACERA uses a completely different tooling stack, and it is often helpful to.try the same code from.(yet another, ) different angle. And indeed from a time to time it helped catch some things that would have been hard to Identity on one platform vs. another.
 
 
Are we still working under the same assumption that projects (/maintainers) should feel free to choose whichever tool is right for your project, language, platform, O/S, or development environment ?
 

I actually wanted to bring it up in that other thread referenced above... as I didn't envision the TSC or anyone blocking one, if they end up not using Jenkins,.if a project prefers to use some other tool...?
 
Thanks, 
 
Jonathan Levi
HACERA  -  To Blockchain with Confidence
 
Unbounded  To Network with Networks
 
M  +1.650.686.9029

 
 
 
 
 
 
 
On Jan 23, 2019 9:38 PM, "Ry Jones" <rjones@...> wrote:
Last year, there was a thread expressing frustration with the Hyperledger CI/CD process as it exists. This morning, I heard from the Ursa team that this is still an issue.
 
I have created a very bare bones wiki page and I would like to have a broader discussion about CI/CD. Please edit the wiki page (or follow up here) so that issues and concerns can be understood.
 
I am interested in all feedback. I know the Fabric team has worked hard on Jenkins, but I suspect they have more input to give. This is a topic I'm passionate about, as removing barriers to developer onboarding is one of my charters.
Ry
 
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry
 
 

 
 


Ry Jones
 

Could I ask any interested party to edit this page and add requirements?

I think it would be better for SNR if I wasn't filtering it.
Ry


On Thu, Jan 24, 2019 at 1:16 AM Iushkevich Nikolai <nikolai@...> wrote:
+1. We definitely need to be in charge of pipeline settings, as it is in our interests to provide a reasonable quality gate for the project.

Nikolai

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

Nikolay Yushkevich <nikolai@...>
 

Hi Ry, 

I’ve recently forwarded you some input from our team. Would this be sufficient for you?

Nikolai

On 25 Jan 2019, at 00:47, Ry Jones <rjones@...> wrote:

Could I ask any interested party to edit this page and add requirements?

I think it would be better for SNR if I wasn't filtering it.
Ry

On Thu, Jan 24, 2019 at 1:16 AM Iushkevich Nikolai <nikolai@...> wrote:
+1. We definitely need to be in charge of pipeline settings, as it is in our interests to provide a reasonable quality gate for the project.

Nikolai

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

Jonathan Levi (HACERA)
 

Nikolai... did you mean to CC the entire mailing lists?

I always found Ry to be super responsive. Just engage directly... not sure there is a need for emails of this nature.

Unless there is another issue that the entire Fabric mailing list should be aware of... I am working under the assumption that not all transactions should be posted on a public, immutable, ledger ;-)

Thanks,
 

On Sun, Feb 3, 2019, 10:36 AM Iushkevich Nikolai <nikolai@... wrote:
Hi Ry, 

I’ve recently forwarded you some input from our team. Would this be sufficient for you?

Nikolai

On 25 Jan 2019, at 00:47, Ry Jones <rjones@...> wrote:

Could I ask any interested party to edit this page and add requirements?

I think it would be better for SNR if I wasn't filtering it.
Ry

On Thu, Jan 24, 2019 at 1:16 AM Iushkevich Nikolai <nikolai@...> wrote:
+1. We definitely need to be in charge of pipeline settings, as it is in our interests to provide a reasonable quality gate for the project.

Nikolai

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry

1 - 12 of 12