Configure GitHub Action for CI/CD

[Marusyk]

C# Cake could be used. An example is here:
https://github.com/Marusyk/grok.net

but it is not mandatory to do the same

actually, we need some CI for pull requests and for releasing the packages

[kanilsz]

@Marusyk, as I understand, we need a separate ci\cd per package?
For CosmosDbMigrations, we need a CI for building only its project + tests (which includes integration tests).
Also, release could be done only for one project at a time.
In such a case, do we need a separate workflow for that?

[Marusyk]

I don't see any reason for this code duplication if we go with separate CD/CD per package.
The workflow is the same for all. If there is test - run the test. If there is something to push to NuGet - push to NuGet.

Also, release could be done only for one project at a time.
what is the reason? it is not microservices! we have packages with clear semantic versioning, if there are newer version of several packages, why not release them? What could the the reason to not release them? if so, we did we create the new version if we don't wanna release it?

[kanilsz]

In such case we will trigger the ci for the whole solution, even when the changes were made only in one place. Is this an efficient approch? Or I am missing something?

[Marusyk]

What do you mean by "efficient"? It is a usual workflow, imagine, you are working in a company and got a task to make small change in the code, you open your .sln file, sln includes 7 projects for example (Domain, Core, Infrastructure, Api, Tests, SDK, EventConsumer) - you made the change in 1 file - then you build the whole solution but the changes were made only in one place. Is this an efficient approch?

another point, there are only 3-4 projects in the solution - but not 102

so, what is more "efficient" in your opinion
A - have 1 CI file and build the whole solution and let dotnet decide what to build and what to not build
or
B - have 3 almost identical code for pipelines, which is hard to maintain and fix later but build only that one project that you need (you will save a few seconds because the build will be a little bit faster)

what approach do you use for your .Common. packages in your company?

[kanilsz]

Efficient in this case is the time/resources required to build and release the stuff.
I caught your point we are choosing maintainability in whis the option 1. For option 2 this is not a seconds but minutes, am not sure that for Service client package it is ok to wait for cosmos db tests to be finished, what if they eventually fail for some reason?
For common package in our project we build all in one but in the same time we don't have any test there especially integrations.
Anyway, I m not the opposite to build and release in one approach. Just thought maybe this could be bettee.

[Marusyk]

do you expect to run the CI multiple times per day? if so, how many? because I don't see the reason to think about resources since they are free for now

it is ok to wait for cosmos db tests to be finished

why is it not ok? do you have some defined deadlines? or does someone pay you for your time. Why the rush?

[kanilsz]

Valid questions. I don't know :) Will move slowly and smoothly from now.