Skip to content
This repository was archived by the owner on Feb 24, 2021. It is now read-only.
This repository was archived by the owner on Feb 24, 2021. It is now read-only.

Should DSC Resource Manifests allow '*' in *ToExport and Include DscResourcesToExport #482

Open

Description

This is something for community discussion and has several parts:

  1. Should we allow '*' in *ToExport Properties in DSC Resource module manifests - e.g.
FunctionsToExport = '*'
CmdletsToExport = '*'
VariablesToExport = '*'
AliasesToExport = '*'
DscResourcesToExport = '*'

If not, then I think we could look at these tasks:

  • Add a guideline?
  • Add DSCResource.Tests (opt-in) to check?
  • Update the module template
  1. Should we include DscResourcesToExport in Manifest that is not set to '*'?
DscResourcesToExport = @(
    'MyResource1',
    'MyResource2'
)

If so, then I think we could look at these tasks:

  • Add a guideline?
  • Add DSCResource.Tests (opt-in) to check?
  • Update the module template

Activity

  1. changed the title [-]Should DSC Resource Manifests allow '*' in *ToExport[/-] [+]Should DSC Resource Manifests allow '*' in *ToExport and Include DscResourcesToExport[/+] on Jan 26, 2019
  2. johlju commented on Jan 27, 2019

    @johlju
    Contributor

    I like this, so I'm for having an opt-in check for this so we don't miss adding a (new) resource to the export list. Nad of course, updating any documentation and template as needed.

  3. stale commented on Feb 26, 2019

    @stale

    This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

  4. added
    staleThe issue or pull request was marked as stale because there hasn't been activity from the community.
    on Feb 26, 2019
  5. added
    discussionThe issue is a discussion.
    and removed
    staleThe issue or pull request was marked as stale because there hasn't been activity from the community.
    on Mar 12, 2019
  6. gaelcolas commented on Mar 12, 2019

    @gaelcolas
    Contributor

    I agree with forbidding the usage of *, but at the same time we need to provide the tooling that helps managing this.
    The opt-in PSSSA rule would be great, but maybe we (I?) should focus on build scripts that just take care of this?

  7. PlagueHO commented on Mar 12, 2019

    @PlagueHO
    ContributorAuthor

    I've added tests in other PS projects of mine to test this and other manifest issues. So might be able to port those across fairly easily with an opt-in rule. Not sure PSSA will work here because it doesn't work on .PSD1 files as IIRC. Could be wrong though.

  8. johlju commented on Mar 12, 2019

    @johlju
    Contributor

    Would be great if you could port the tests so this were opt-in. Thought of this the other day as I forgot to do this in those repos I maintain. Having an opt-in rule reminding to opt-in would be great! :)

  9. gaelcolas commented on Mar 26, 2019

    @gaelcolas
    Contributor

    Maybe we should change the opt-in to opt-out... so that any drift from guidelines is conscious and visible?

  10. johlju commented on Mar 26, 2019

    @johlju
    Contributor

    We don’t want to break any repositories so they can’t be released since there are no one normally available to fix any CI problems. There for all tests we add are opt-in.

  11. PlagueHO commented on Mar 26, 2019

    @PlagueHO
    ContributorAuthor

    We did originally try the opt-out model on some rules a couple of years back but had to back it out as it broke many repos. We also had non resource kit DSC resource module owners that use DSCResource.Tests and they may not fully adhere to DSC resource kit guidelines. Especially as there were many repos with no maintainers who could fix the potential violations. If it were just the repos I maintain I'd be good with opt-out 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionThe issue is a discussion.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions