🚀[Feature]: Have the option of not deleting prereleases

[mchave3]

Description

In connection with Process-PSModule, would it be possible to have an option not to delete prereleases in the Github release list ?
I think it would be nice to have the choice of keeping them or not, so as to have at least a history of changes in Github.

[MariusStorhaug]

Im been planniing a while to just bundle the entire Process-PSModule into one repo and have the features and stuff there instead of having separate repos. Makes it easier to follow it as one process.
All the actions have the same lifecycle and are deeply dependent on eachother.

What would make sense here to me, is a settingsfile that the Process-PSModule uses for controling what the different stages do:

Settings:
  Testing:
  - SourceCode:
      PesterSettingsFile:
  - Module:
      PesterSettingsFile:
  Build:
    PublishArtifactWithRelease: true
  Documentation:
    PrereleaseDocumentation: false
  Publishing:
    AutocleanupPrereleases: true

This would make it easy to have all the settings in one place, track the issues in one place and make development of the process better. With this, adding feature flags would be somewhat easier, rather than having to use the inputs on the workflow. Thoughts?

[mchave3]

I think it's an excellent idea ! Do you have an ETA on the implementation of this new workflow?

[MariusStorhaug]

New as in the one with these settings? That would be v4. I am thinking I would add it on first step, of this iterative list of things that need to change:

• Move all *-PSModule actions in to Process-PSModule
• Split out doc stuff from Build-PSModule -> Document-PSModule as an internal action in Process-PSModule)
• Refactor test to do more parallelism, one job pr *.Tests.ps file. -> Introducing the Invoke-Pester action

[MariusStorhaug]

Realized i gave no ETA. Thinking a lot of this is done over the weekend. Plan is to get pester done first. Split of Build-PSModule I can do later. Just need to speed up testing on GitHub, so create Invoke-Pester action first, fix parallelism on Test-PSModule first in the move.

[MariusStorhaug]

Then again, it shouldnt be hard moving all, which you shouldnt feel at all other than the repos disapearing.

[MariusStorhaug]

@mchave3 Already working on the co-location. Seems to be fine to move. Will do it bit by bit. The technical stuff now and the practical stuff in a while. Need to update documentation aswell, but can likely just update when I know more about the sturucture it will have in the end.

[mchave3]

Perfect, can't wait to see these changes.

[MariusStorhaug]

The implementation is taking abit longer than expected. What I am trying to change now on the design is:

• Use of nested workflows within Process-PSModule as you cannot co-locate the action code. When using an action, the action repo is checked out; when using a reusable workflow, the workflow file is expanded into your workflow (no code checkout or ability to reference anything in the workflow repo). So a bit of a snag on that.
• Allow for parallel testing of PSModule tests and test suites from the module. Design im going for here is to use subfolders in the tests folder to be one test suite, and each of these gets its own job, so they can be processed in parallel. Status and report aggregation would happen after it (similarly as it is today, just needs more functionality later, i.e. combining JaCoCo tests to get full coverage reporting.
• Set up the settings file for it.

[MariusStorhaug]

@mchave3 Sorry for taking so long, but there are so many improvements that are coming with v4.

In regards to your question of not doing cleanup of prerelease; that has been in there all along.. Its weird I didnt remember. There are two things you can do to control this:

1. Use the default place of ConfigurationFile thats present in Publish-PSModule.

  ConfigurationFile:
    description: The path to the configuration file. Settings in the configuration file take precedence over the action inputs.
    required: false
    default: .github/auto-release.yml # This is the configured name, its just a copy paste issue from the "Auto-Release" action that was made first.

This will take all the settings that you would otherwise send to the action, and would configure it that way.

2. Configure the AutoCleanup property in the file.

  AutoCleanup:
    description: Control whether to automatically delete the prerelease tags after the stable release is created.
    required: false
    default: 'true'

All of this is taken from the action.yml from Publish-PSModule.

Just so you are also up to date with the v4 of Process-PSModule, it is on its way this weekend I believe. Will refactor so that all configurable settings in the process use another file called .github/PSModule.yml and contain sections similar to what was described above. What is taking time right now is aligning design of all actions to use a workdirectory parameter to determine "root" folder of the repo. Just refactoring so that pathing is dynamic based on that. Why? One of the settings will allow you to modify the folderstructure as you see fit.

I am also aligning a new naming convention on envvars, so they "never" clobber each other. Names of envvars that link action inputs with main.ps1 will be following <ORG_NAME>_<REPO_NAME>_INPUT_*.

Most importantly for me, is the dynamic parallelism of tests. It will now read folders from the tests folder and make multiple jobs of that. If there is only a file and no folders, it will still work as now with one job for testing the module.

[mchave3]

Hi @MariusStorhaug ,

Excellent work. Takes all the time needed! Can't wait to test this v4 and put it into production in my project workflow.