Command Dispatcher, Processor, and Distributed Task Queue. https://www.nuget.org/profiles/BrighterCommand
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
Once I get a passing build, I'll look at a DotNet Foundation submission again
@/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
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.
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
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
It will take me a while to grab that, but it's a great first issue if anyone was looking to contribute
I'll add a Nuget feed etc to Darker too
I need to fix up a Release build we can trigger for NuGet deployment for both
Again it's just a basic build for now, because we don't have the same test separation we have with Brighter, I think it would be nice to achieve that, as the feedback is far better. It doesn't deploy the package to PyPy as yet. I need release builds that deploy across the board
But everything is in GitHub Actions now
OK, so the Kafka build has been fixed. A combo of issues with the GitHub Actions services (don't have a blank line between them folks), Kafka 1.5+ no longer defaulting to auto-create topics, and the lack of our usual publisher/creator classes for mapping our message type onto the native type. All of those are fixed. I dropped all apart from one test, as badly written and have some fixes for Kafka to go in over the next couple of days. So this is really just a confidence test. Some of those 'fixes' will be useful to complete the Redis Streams work, which has similarities to Kafka in some requirements. For example, we currently use Null for the partition key value on Kafka. We probably don't want random assignment, but an actual well identified 'partition key' on our message type, that is a string type. We also want to change how we handle getting and committing the offset etc. So expect some more changes here.
I worry about stored value as we don't drop releases very fast, and I would like to up our cadence to at least once a quarter. I'm not sure that a framework should release a lot faster than that.
@holytshirt I know you had some release issues, to do with the changes to the schema of the Db. Can you remember what those were? I'd like to fix if we can, and start releasing on a regular schedule.
@iancooper if your build is always creating versioned packages and adding to them to the github package feed, you can just choose a package to promote to nuget?
@iancooper Also No Outbox doesn't work
@holytshirt I don't know if I can promote a NuGet package from the GitHub feed. I was assuming that 'good enough' was get a green build, test, and then trigger a build by tagging. There is complexity about build we test vs. build we tag there, I guess it's a question of do we think it's a real risk
Right, are there issues for those two Outbox issues, then I can tackle them as a priority.
I can raise them, but if you have detail that would help
@holytshirt PS tempted to adopt this. Thoughts? https://www.conventionalcommits.org/en/v1.0.0/
@iancooper I've created a project for finishing and releasing V9 https://github.com/BrighterCommand/Brighter/projects/5