PowerShell
New resource module: GroupPolicy
I have resources for setting GP inheritance, importing GPOs from backups, and linking existing GPOs. These are MOF based resources.
I'm working on updating these to meet the contribution guidelines and would like to contribute them as a new module once they're updated.
Do we still need to name them with an x (ex: xGroupPolicy)?
Anyone have a recommendation on what to do about parameter sets? For example, I'm thinking of having two resources for importing GPOs - one for importing by GUID and one for importing by Name because TargetGuid and TargetName are in separate parameter sets for Import-GPO.
Is this the recommended approach?
If they ultimately both import a resource, I'd instead simply build a single resource and have two parameters: Name and NameFormat. Make "NameFormat" optional and default to "DisplayName" but accept "DisplayName" or "GUID".
That's assuming there's no other difference between the two resources.
HI @corydwood Glad to hear you are planning on contributing your module. Please still include "x" in your new resources. We will be dropping "x" across all modules in a consistent manner.
Regarding the second question, I agree with @Justin-DynamicD single resource sounds like the way to go here.
All the best!
@Justin-DynamicD - Thanks for the idea! I'll work on coding it that way. @KarolKaczmarek - Thanks for the info. I'll plan on keeping the "x" in the resource name.
Not to hijack the thread ... but should we still be using "c" for community resources that we publish to places like PSGallery directly or has differentiating between (x)perimental and (c)ommunity kind of fallen to the wayside?
"c" no longer makes sense after we've open sourced ResourceKit on GitHub. It's all community now :+1: Also, we encourage everyone to contribute new resources under PowerShell org.
its been so long ... i no longer remember. I just remember seeing a naming standards published somewhere that said "x" was ms reserved for experimental, "c" was community, and no prefix were modules officially supported by MS.
Am I dating myself?
You remember correctly, that was our original message regarding naming prefixes in order to allow clear distinction between modules shipped by Microsoft and their forks/modules developed by community. After moving development of DSC Resource Kit on GitHub it's no longer valid and information about it has been removed from all repositories/PSGallery pages.
Looks like i better update some of my now dated modules/dsc resources then!
I have the xGroupPolicy module ready to submit.
How do I complete the option, "Allow the PowerShell organization to fork your repository and use that fork as a submodule of DscResources"?
Here's the module: https://github.com/corydwood/xGroupPolicy
@PlagueHO - I saw that. It just tells you the two options for contributing a new module, but not how to do it. It says to follow up in the issue with the option you'd like to use, which I'm doing.
How do I allow the PowerShell organization to fork my repository and use that fork as a submodule of DscResources?
Can you just take the link to the module I included above and just fork it, or do I need to do anything else on my end?
Oh right - no I think the MSFT guys can just review the module with the link you've provided. Pretty sure they don't need anything else. Although only the MSFT team can confirm that :smile:
@corydwood I just posted a new guide for submitting new resource modules to the DSC Resource Kit.
I cannot access this link you provided to your repo: https://github.com/corydwood/xGroupPolicy
@kwirkykat I've updated my module with the items from the new guide, except the Examples folder and creating a new, empty branch.
All of the examples are contained in the README.md file. If I put them in an Examples folder as well, there will be duplication of information, which isn't recommended. Should the examples be moved to an Examples folder instead of being in the README.md file?
Can you please expand on the steps to create an empty branch and creating a pull request to that branch? I haven't had any luck doing this by following steps I've found online.
I just tested accessing https://github.com/corydwood/xGroupPolicy without being signed into my GitHub account and was able to access it, so I'm not sure why you're unable to access it.
@corydwood - glad it isn't just me :smile: I haven't been able to figure out the empty branch thing yet either!
@corydwood If I copy and paste the link it works, but the clickable hyperlink doesn't lead to the same URL.
Yes, you will need the examples as runnable scripts in an Examples folder instead of the examples in the README. Also you will need to rename the repo/resource module to GroupPolicyDsc. Otherwise looks pretty good :+1:
This blog seems to have the right process for the empty branch problem. Apparently you will need to create 2 new branches. I will update the documentation.
@kwirkykat I've updated the module with the new guidelines. I've also created the PR and it is ready for review.
Module submission progess:
- [x] 1. Separate public repository created
- [x] 2. Review pull request open
- [ ] 3. 1st reviewer approved (Katie)
- [ ] 4. 2nd reviewer approved (Travis)
- [ ] 5. 3rd reviewer approved
- [ ] 6. Tests passing
- [ ] 7. Repository transferred
- [ ] 8. Module released
Hi @lwajswaj - new community created modules are no longer being added to the DSC Resource Kit. Instead there is now a program where community created & maintained modules can be submitted to be reviewed by the community and will be linked to within this Repo (you can hear more of the discussion about this in this community call: https://github.com/PowerShell/DscResources/blob/master/CommunityCalls/2017-09-27/notes.md).
But you can still find this excellent and high-quality module here: https://github.com/corydwood/GroupPolicyDsc
@corydwood - are you still wanting to get your resource linked over here? It would be good to get your module linked.
Are there still interest of adding the GroupPolicy resource module to the DSC Resource Kit? If so I like to help getting this reviewed according to the new process of getting a resource module added to the DSC Resource Kit. I have opened an issue to update the text on How to do a new resource module submission, but basically if we gonna submit this resource module to DSC Resource Kit we need to make sure it follows the Quality Governance.
I would say "yes" just for the fact I'm currently building automation around Domain Controllers and a step would be to add GPOs for user accounts, among others, where this module would be really helpful. Otherwise, I can just consume it from the source; but current DSC Toolkit is missing a part on Active Directory then.
@lwajswaj the resource would be linked from the Dsc Resource Kit to the owners (@corydwood) repository, so you would still need to get it at the "source". The difference to link it to the DSC Resource Kit is that it would mean the resource module follow the guidelines and quality of a resource module that DSC Resource Kit try to up hold. Antoher option would be to add the resources to the existing xActiveDirectory resource module that is under the PowerShell DSC Team umbrella of the DSC Resource Kit.
@PlagueHO - Yes. I am still interested in getting this module linked to the Microsoft repo.
@corydwood great! Please send in a PR adding your resource module as a submodule which will link your repo from this repo. See how Michael did it here https://github.com/PowerShell/DscResources/pull/346/files.
It's a new process so I think we have to take it step by step and learn as we go.
@corydwood I have sent in a PR that adds the steps to do a new module submission, until that is accepted, please look here at the proposed texts.
New module submission: https://github.com/johlju/DscResources/blob/b899c99aa1cab6a481c060c26ab0db5e6e4d4d9c/NewResourceModuleSubmissions.md
Issue template: https://github.com/johlju/DscResources/blob/b899c99aa1cab6a481c060c26ab0db5e6e4d4d9c/.github/ISSUE_TEMPLATE/New_resource_module_submission.md