Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 28 23:39
    preardon commented #1855
  • Nov 28 23:26
    iancooper commented #1855
  • Nov 28 22:53
    preardon commented #1855
  • Nov 28 21:56
    iancooper commented #1855
  • Nov 28 18:53
    iancooper commented #1855
  • Nov 28 17:17
    preardon commented #1855
  • Nov 26 09:08
    zhchlmm starred BrighterCommand/Brighter
  • Nov 24 17:21
    vinhnxv starred BrighterCommand/Brighter
  • Nov 24 10:06
    StevenTCramer starred BrighterCommand/Brighter
  • Nov 23 20:28
    adersonrangel starred BrighterCommand/Brighter
  • Nov 23 12:33
    dotlive starred BrighterCommand/Brighter
  • Nov 23 12:05

    holytshirt on 9.0.1-preview.5

    (compare)

  • Nov 23 11:50

    holytshirt on master

    Ensured a new CommandProcessorP… (compare)

  • Nov 23 11:50
    holytshirt closed #1866
  • Nov 23 11:32
    preardon assigned #1867
  • Nov 23 11:32
    preardon opened #1867
  • Nov 23 10:48
    preardon synchronize #1866
  • Nov 23 10:02
    holytshirt commented #1857
  • Nov 22 22:50
    preardon synchronize #1866
  • Nov 22 22:16

    dependabot[bot] on nuget

    (compare)

Ian Cooper
@iancooper
Now normally I would assume that the Handle() method calls into the domain to do it's work.
So, our intent doesn't require two generic parameters, the only thing we believe is generic is the set of parameters that are passed to the handler.
So what would I do if I wanted to vary behavior of the handler? Most likely I would pass an interface parameter into the constructor of the handler to represent that which varies, in other words use the Open-Closed Principle.
Often OCP provides an alternative to parametric polymorphism
Ian Cooper
@iancooper
Is it possible to give us an example of what you are trying to achieve, so that we can see why you are looking at using generics to solve a problem in the handler and see if an alternative is possible for you.
Andrew Jaffie
@ajaffie
I ended up getting something to work, so thank you for your time
Ian Cooper
@iancooper
@ajaffie No worries. If you want to share the scenario, in case it is something we need to think about, please do
Ian Cooper
@iancooper
@holytshirt Wondering if our new build process should focus on GitHub Actions over Azure DevOps? Seeing some suggestions that most of the dev team have moved over and Azure DevOps is effectively 'maintenance mode'
Seeing as you are doing paternity, I may try and fix our CI that way, and see what happens.
Ian Cooper
@iancooper
@/all Behind Working Build and Redis Streams is "Death to Bugs". There is now a triage board for "Death to Bugs" and I want to start focusing on killing high-priority bugs within two weeks.
Toby Henderson
@holytshirt

@iancooper popping my head up. AppVeyor should be working and the feed should still be there.
The Azure DevOps one is mostly working... @DevJonny might be able to help

There is a branch testing Actions out, just really simple so far.
https://github.com/BrighterCommand/Brighter/tree/Testing-Actions

@iancooper a few issues I have with Actions are:
  • How to do semantic versioning for build and package.
  • There's no test reports, you only see something if the a test fails and you can't tell if all the tests are running (this may have changed now)
Toby Henderson
@holytshirt
@iancooper I would like to use actions as it is "easier"
Ian Cooper
@iancooper
@holytshirt I am having a play, just done lots of learning about Actions. I'll see what I can get working. I'll check on AppVeyor too. If AppVeyor is working then I can get a simple GitHub build working for check-ins that tests Core, so we can make easier decisions, and then look at building out transport/storage build tests that work on check ins to those repos.
Having fun because it's been too long since I played with build stuff over letting you do it, and its making me get to grips with it again
Ian Cooper
@iancooper
@holytshirt Got the Core Tests running. I'm actually thinking of using separate jobs for each transport/database. I could also split up the docker containers to each job. That way, we get a fail for the given failing transport. I might make it not required, that way you can see if the core tests pass and await ignore the transport tests if you do not need to confirm that at that point. So if your change doesn't affect that other transport. Given the transport and Db tests are usually what is flaky for us, it might be the easiest way to understand whether you could move on, or needed to halt]
Ian Cooper
@iancooper
PS The AppVeyor builds seem to take forever to run. Maybe they are no longer keen on our free patronage :-)
Ian Cooper
@iancooper
We were getting a number of issues with implicit dependencies. The tooling suggested making those explicit instead. I know we have dropped these before, but I added them back in because the tooling implies that it is the cause of package downgrade issues in the build.
Ian Cooper
@iancooper
@holytshirt PS the flaky Timeout tests on AppVeyor are not flaky on GitHub. I wonder if they are sensitive to resource constraints on AppVeyor somehow. It's likely that we will replace with Polly Timeout for implementation anyway, but the Core Tests seem reliably green via GitHub Actions
Ian Cooper
@iancooper
@/all Expect some choppy build notifications whilst I get the various parts of our GitHub actions script working
Ian Cooper
@iancooper
@holytshirt Wow, Liblog really kills my attempts to create a NuGet package with dotnet pack on GitHub. Works fine locally, but I wonder if it's a weird dotnet version issue
Ian Cooper
@iancooper
@holytshirt Maybe I should just fix the 'remove liblog' issue and be done with it
Toby Henderson
@holytshirt
@iancooper you know that nuget packages are created at build time, you don't need to do dotnet pack ...
Ian Cooper
@iancooper
@holytshirt Replied on the thread
Ian Cooper
@iancooper
The WiP PRs around the GitHub Actions are just that. Not sure if the draft flag impacts running the actions, will check
Ian Cooper
@iancooper
I have GitHub actions building, running core tests across Unix, WIndows, and MacOS and transport tests on Unix against Redis and RMQ. I'll keep moving through the transports and Dbs. I'll need to figure out the most effective way to do cloud services - I guess it depends if I can talk to AWS from a GitHub action container easily.
My goal is to get it working, then improve it.
Some items, such as using built artefacts in the tests, turn out to be painful, trying to run a DLL from dotnet test tends to result in warnings about missing testhost.dll despite the SDK and Testrunner being referenced in the test project. It's not much cost to rebuild for a test, just slightly unsatisfying.
Priority though is a reliable build
I have commented out the Timeout handler tests for now. I want to replace with Polly anyway, and they are too fragile to run as part of the CI process
There is a new badge at the base of the README file to indicate the GitHub build status
Ian Cooper
@iancooper
@/all I also updated the README because it was woefully out of date.
Once I get a passing build, I'll look at a DotNet Foundation submission again
Ian Cooper
@iancooper
@/all As you can see, work on the new build is progressing. I just need to fix up AWS, EventStore and Kafka. AWS will probably be next as there is is good support for AWS from GitHub Actions. EventStore I suspect needs a health check, and Kafka is the big pain because of the way discovery works. It's possible that the Kafka job may have to use Docker Compose, but I would like to see if I can figure out how to get it working without that first, as it's an extra dependency.
I am using separate jobs over steps to run the complete suite because the feedback is better that way. We can more easily see on the repo pages which part of the CI build failed, without having to open up the build and review the individual steps. Given that the jobs are parallelized after the core tests run, I am not sure that is a performance problem. I also quite like the way that we isolate the dependencies for each transport test, but that was not the primary reason for this approach
Once we get the CI build working, I'll look at triggering a deploy to NuGet via tagging a release.
At that point we can probably retire AppVeyor, which has become slow and unreliable
It's stalled work on Redis a little bit behind it, as I only have so much time. I would like to get Redis and the CI/CD builds done by end of year and work on our foundation submission
If any of you have capacity - Death to Bugs project is a good starting place as I would love to kill some of those bugs that have been hanging around for a while
Ian Cooper
@iancooper
I'll try tackle Darker as part of the GitHub actions work, as well as Brightside. Let's see
Jonny Olliff-Lee
@DevJonny

If any of you have capacity - Death to Bugs project is a good starting place as I would love to kill some of those bugs that have been hanging around for a while

Once I'm back from paternity leave (starting soon hopefully) I've got a couple of bits to finish off on our Blazor project then I will be free to pick up some bugs.

Ian Cooper
@iancooper
@DevJonny That would be cool. Be nice to get it into a shape that we could proudly go to the .NET Foundation with IMO
I have lots of ideas for 'next' but I want us to get something reliable and stable first, then we can address new ideas. Maybe we can even have a meeting about that phase at virtual NDC London again :-D
Ian Cooper
@iancooper
Apologies, the EventStore job was a mis-merge by me (not sure when). It was supposed to be on a branch. As it only fails one job, and I still need to fix it, along with Kakfa and AWS, just ignore over my making it worse with a rollback. I am suspicious the event store issue is the health check
Ian Cooper
@iancooper
OK, the EventStore job is fixed. On to AWS as GitHub Actions has some support that ought to allow us to run our SQS tests directly on AWS
Ian Cooper
@iancooper
@/all BTW I was demoing Brighter at JE, and I think our sample code needs a little bit of a clean up, and to lean more heavily on HostBuilder
It will take me a while to grab that, but it's a great first issue if anyone was looking to contribute
Ian Cooper
@iancooper
@/all Darker now has a basic GitHub Actions build. I'll fix it up into separate jobs, like Brighter, so that it is easier to see without having to open the build up, what steps an and passed.
Ian Cooper
@iancooper
I killed the AppVeyor build for Darker as it was failing due to SDK versions.
I'll add a Nuget feed etc to Darker too