You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 24, 2021. It is now read-only.
Repository navigation
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
changed the title [-]Should DSC Resource Manifests allow '*' in *ToExport[/-][+]Should DSC Resource Manifests allow '*' in *ToExport and Include DscResourcesToExport[/+]on Jan 26, 2019
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.
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.
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?
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.
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! :)
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.
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 😁
Activity
[-]Should DSC Resource Manifests allow '*' in *ToExport[/-][+]Should DSC Resource Manifests allow '*' in *ToExport and Include DscResourcesToExport[/+]johlju commentedon Jan 27, 2019
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.
stale commentedon Feb 26, 2019
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.
gaelcolas commentedon Mar 12, 2019
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?
PlagueHO commentedon Mar 12, 2019
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.
johlju commentedon Mar 12, 2019
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! :)
gaelcolas commentedon Mar 26, 2019
Maybe we should change the opt-in to opt-out... so that any drift from guidelines is conscious and visible?
johlju commentedon Mar 26, 2019
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.
PlagueHO commentedon Mar 26, 2019
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 😁