Create new CI and Release workflows. #350
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #349. Please check the related issue for more details.
Removed the old workflows and created two new ones. I think the workflows now are stupid simple :)
ci.yml
- Build and test, triggered on pr and push on main. Triggered only if there are changes in the library projects. All other changes for docs or sample apps won't trigger anything. It's tedious if CI is triggered on each doc change.release.yml
- Triggered on release publish. We're anyway always creating releases from Github, so let's use that event. This will publish all three packages (but that's what we're always doing). If in the future we need to publish them independently, we might use different tags for each package, but for now, that seems unnecessary.The solution contains sample apps too, but I didn't want to build them as part of the workflows. So, instead of passing all the required projects as an argument to
dotnet build
, I created a solution filterci.slnf
which contains only the necessary projects. I think this was a great trick, and makes the yml files way cleaner.