search

ccnet / CruiseControl.NET

CruiseControl.NET is an Automated Continuous Integration server, implemented using the .NET Framework. Downloads at sourceforge. The documentation can be found at:
https://ccnet.github.io/CruiseControl.NET
Other
407 stars 225 forks source link

Roadplan for CruiseControl.NET #264

Open savornicesei opened 5 years ago

savornicesei commented 5 years ago

Hi @RubenWillems, @obones Based on your discussion, I would love to continue the discussion where CC.NET could go given the current state of the development tools and the advent of CI/CD.

Some questions that I have:

  1. What's the relation with ThoughtWorks ? Even the license is not a well-known OSS license but a "ThoughtWorks Open Source Software License".
  2. Can the license be changed to MIT/ Apache 2.0? I think agreement from all contributors is needed.
  3. How come the latest releases (up to 1.8.5) and release tags are missing from GitHub?
  4. There are pull requests waiting to be incorporated in the code base. It would be nice to do a new CC.NET release
  5. We could configure CC.NET to be automatically build in appveyor / travis. No need for additional infrastructure except GitHub and its OSS-friendly (aka free) ecosystem
  6. The UI is sooo static
  7. The build log is sooo hard to follow (perhaps there's an xslt template for pretty view)

I'm more familiar with Jenkins. The current project I'm working on is using svn and CC.NET but the plan is to move to Git and Bamboo as CI server. But as a .NET developer (and a linux user) I would love to have more CI-related tools build in .NET instead of java (like Jenkins, Bamboo, SonarQube, Nexus).

Best, Simo

RubenWillems commented 5 years ago

Hi

As far as I can remember, there is no problem going to MIT license, the relation with Thoughtworks is in fact cut. About the pull requests, that can be done. I need to check if they are on the 1.8.5 release, or on the 1.9 Maybe we should clean up the 1.9 release, there are some unfinished items there.

About the automatic building, if you could provide a link or documentation on how to do it, that would speed up the process.

What's the problem with the build log? I used it for many years, and you can easily use xslt to transform it to a nice view. ° one for the unit tests ° one for the build ° ... So I do not see what makes it hard to read the build log in your system. If you want, you may private mail me with a build log, so I can take a look at it. (remove paswords and the like) and tell me what you would like to have.

The UI .... That's indeed static, and web development has changed a LOT in the past years. I'm a bit scared of tackling the web UI, because that would mean a total re-write. Now it is indeed static, but also very basic. Anyone with a bit of web experience can make minor adjustments.

What would we choose for the 'engine' ? ° asp mvc ° asp core ° ...

many things to decide, and I have no real experience in web development, changing an existing program is totally different than setting one up from scratch with a good architecture.

I know there is a lot of code in the web ui, that can be ditched, because that functionality is now standard. ° objection --> Ninject ° asp handlers --> asp.net core ° ....

I would like to change it to .Net core, as that would mean Linux is easily supported. Dropping the windows specific items (registry and the like) should not pose a real problem I think. Only the windows service part should have a linux daemon. I do not know if that can be done in the same project.

If there some people helping, this is a good way foreward, but I'm not doing this alone ;-)

any thoughts / tips are welcome.

with kind regards Ruben Willems

On Fri, 19 Apr 2019 at 10:55, Simona Avornicesei notifications@github.com wrote:

Hi @RubenWillems https://github.com/RubenWillems, @obones https://github.com/obones Based on your discussion https://github.com/ccnet/CruiseControl.NET/issues/263#issuecomment-478644112, I would love to continue the discussion where CC.NET could go given the current state of the development tools and the advent of CI/CD.

Some questions that I have:

  1. What's the relation with ThoughtWorks ? Even the license is not a well-known OSS license but a "ThoughtWorks Open Source Software License".
  2. Can the license be changed to MIT/ Apache 2.0? I think agreement from all contributors is needed.
  3. There are pull requests waiting to be incorporated in the code base. It would be nice to do a new CC.NET release
  4. We could configure CC.NET to be automatically build in appveyor / travis. No need for additional infrastructure except GitHub and its OSS-friendly (aka free) ecosystem
  5. The UI is sooo static
  6. The build log is sooo hard to follow (perhaps there's an xslt template for pretty view)

I'm more familiar with Jenkins. The current project I'm working on is using svn and CC.NET but the plan is to move to Git and Bamboo as CI server. But as a .NET developer (and a linux user) I would love to have more CI-related tools build in .NET instead of java (like Jenkins, Bamboo, SonarQube, Nexus).

Best, Simo

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ccnet/CruiseControl.NET/issues/264, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEUZAIBP6SL2DVCKXXEU2TPRGCINANCNFSM4HHC4XHA .

savornicesei commented 5 years ago

Hi @RubenWillems

1.9 release

It was stated in the 1.8.5 release that the next will be 1.9 but ... Where is the 1.9 branch? Currently there's no 1.9 branch in GH and quite a lot of differences between 1.8 branch and master. The tags also stop at ccnet_1_4_5_CTP. I suppose the branching strategy in SVN was to create a next-release branch and work on it.
On git, we should have the master as the main development line - containing only finished features. Is it possible to acomplish this for 1.9? or just release 1.9 from its svn branch?

vNext release (2.0)

This should bring .NET Core 3.0 to the table and any other unfinished feature still lingering around. Plus:

Next steps (IMHO)

Misc

Do you still have a backup of the old site (running on ChilliProject)? I'm more interested in the list of tickets and their status, including feature requests. Is it possible to have the SVN still available in sourceforge but in read-only mode? And a note on the site's frontend that it moved to github? Again, it would he helpful to get a copy of the old SVN repository.

Best, Simo

mintsoft commented 5 years ago

Just to chime in here, I think all of those look like steps that are worth taking. I'd suggest that for 1.9 it'd make the most sense to base it on master. I use a fork of ccnet with a few additions built from master and it's absolutely fine. I don't think there's any regressions that I've come across vs 1.8.5 that would preclude it from being regarded as stable enough for release.

mintsoft commented 5 years ago

In that light, I think it might be worth cherry picking a few high value PR's:

savornicesei commented 5 years ago

@mintsoft Let's not forget git ones: #206, #254, #258. For #163 - a decision is required.

Perhaps it will be easier to merge all on master, stabilize it and release 1.9 from it.

Digging through web archive seems like the project switched several systems until landing on GitHub that's why there are PRs but no tickets related to them. I would really like to know what tickets were left behind. Or just recreate/import them here, on GH.

mintsoft commented 5 years ago

Perhaps it will be easier to merge all on master, stabilize it and release 1.9 from it.

Yeah I think that's definitely the easiest approach

RubenWillems commented 5 years ago

The master branch contains the code for 1.9.

In the past we developped in the main branch, and when we decided that all features where done for a release, we made a release specific branch. From that point on, only bugfixes and small tweaks like UI were done in that branch, and ported back to the main. Development could continue in the main branch of course. I see a there seems to be intrest in a new release, the question will be what items would be included? if they are not breaking with 1.8.5 we could make them in the 1.8 branch and release 1.8.6. For all the other stuff, like build on Linux, use .Net core, I would place those in the main branch, and when things look ready, we can decide when to make a branch for 2.0. The 1.9 can be a nightly build range. Or we can leave the 1.8 as is, clean up the 1.9 branch (basically revert to 1.8.5 I think) and merge in the most wanted items. That way there is not a problem with compatibility. And when 1.9 is out, do all the core rework (making a 1.9 branch for bugfixing) I personally prefer cleaning up the main / 1.9 branch, and merge the most wanted items in there.

RubenWillems commented 5 years ago

There 2 new projects added one for the 1.9 release and one for the 2.0 release. As suggested a 1.9 release with the most wanted improvements, and a 2.0 for the major rework. Any commnents are welcome.

RubenWillems commented 5 years ago

I'm trying to port CCNet to .NEt Core. Stuff done so far : ° netreflector + tests ° CCNet

Now the problem starts with the tests, because we used various mocking libraries through the years :-(

Questions : ° should we still use mocking libraries, or do we write our own fakes ? this ensures that we do not have this problem again in the future, but it can be a lot of work ° if we use a mocking library, which one? the only one I could find after a quick search was : MOQ https://github.com/moq/moq I never used it though --> learning this library can also be a lot of work

any preferences ?

any second thoughts, suggestions

obones commented 5 years ago

Here at work, we are using MOQ 4.10 (https://github.com/moq/moq4) with .Net Core, so I would feel right at home.