Consolidating GitHub actions and workflows for building and releasing the PowerShell modules

[FH-Inway]

@Splaxi Since we do not have organization discussions*, I created this discussion on the most active repository, in case others are interested.

As mentioned in d365collaborative/d365bap.tools#21, I started work in consolidating the GitHub actions/workflows in use in the d365collaborative repositories. With the addition of d365bap.tools, there are now at least 4 repositories that in regards to building and releasing the PowerShell modules, essentially do the same thing (or should do the same thing). While it will take some time consolidating it all, I think it is worthwhile. The current approach of eventually (for some repos very eventually 😄 ) updating each repo individually on an ad hoc / as needed basis feels cumbersome and error prone.

That said, when comparing the current actions of d365bap.tools with d365fo.tools, I noticed several differences, both in the actions and the PowerShell scripts used by them.
The main thing seems to be the validation, which for d365fo.tools is done in 4 steps (general unit tests, public functions unit tests, internal functions unit tests and individual unit tests), while d365bap.tools only has 1 step (which seems to correspond to the steps 1 and 4 of general and individual unit tests of d365fo.tools).

Before I dive deeper into that, I'd like your feedback on whether this seems worthwhile to you as well.
And if so

• should the validation for all modules follow the seemingly more sophisticated d365fo.tools approach?
• what should be the name of the repository that holds the consolidated actions?

For my current experiment on this, I went with the name d365.psmodule-alm (alm as in application lifecycle management), but I do not really care for it.

* Could we enable organization discussions for topics like this where multiple repositories are affected? This would require creating a profile repository named ".github" (see https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#adding-a-public-organization-profile-readme) and then enable the organization discussions feature with that repository at https://github.com/organizations/d365collaborative/settings/discussions

[FH-Inway]

Next steps have been taken:

• Use build release template from alm repo d365bap.tools#24
• adds a manual build and release action that creates a release on PowerShell Gallery and GitHub #821

[Splaxi]

The main reason for the the splitted validation in d365fo.tools - is purely performance / faster feedback. It takens forever to validate every single unit test we have in place, when working on new stuff or refactoring it.

Does it pay off in the daily working with the module? Maybe not - your own experience is equally as important as my own.

[FH-Inway]

Thanks for the merges, that should enable me to do releases of d365fo.tools on the PowerShell gallery as well. Let's wait for the next batch of changes, then I will try it. If that works, we can also switch to a fully automated release triggered by a merge on master.

Regarding validation: I think for the release build, it is ok to do them all in one go. Those validations are unlikely to fail, since the same validations have been done in advance multiple times (at least twice, once during the pull request build and then during the build after the merge to development).

This also does not change how the validation is done so far, so no harm done.

To be honest, I do not use them often directly during my daily work with the module. It is usually easier to just push the changes to Github and then run the validation action there.