Add documentation, workflows, updated config, standardized some syntax, and much more.

.ansible-lint

@@ -14,7 +14,7 @@ exclude_paths:
   - .cache/ # implicit unless exclude_paths is defined in config
   - .github/
   - collections/ansible_collections
-  - meta/runtime.yml
+  - molecule/
 # parseable: true
 # quiet: true
 # strict: true
@@ -54,6 +54,7 @@ use_default_rules: true
 # still visible, making it easier to address later.
 skip_list:
   - skip_this_tag
+  - meta-runtime[unsupported-version]
 
 # Ansible-lint does not automatically load rules that have the 'opt-in' tag.
 # You must enable opt-in rules by listing each rule 'id' below.

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,97 @@
+---
+# reference: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests
+name: "Bug report"
+description: "Create a report to help us improve."
+labels: [
+  "bug"
+]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Reporting Bugs ld follow some simple rules:
+
+        - **Check**, if you can find similar bugs
+        - **Describe** what is happening and what should happen
+        - **Explain** how to reproduce the problem
+        - **Add** more details and attachments
+        - **Follow up**, if somebody is having questions or needs more details
+
+  - type: textarea
+    id: description
+    attributes:
+      label: "Description"
+      description: Describe the bug
+      placeholder: A clear and concise description of what the bug is.
+    validations:
+      required: true
+
+  - type: textarea
+    id: reprod
+    attributes:
+      label: "Reproduction steps"
+      render: Shell
+      description: Paste an example playbook that can be used to reproduce the problem. This will be automatically formatted into code, no need for backticks.
+      value: |
+        ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: currentbehavior
+    attributes:
+      label: "Current Behavior"
+      description: Please describe the results you received
+      value: |
+        ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: expectedbehavior
+    attributes:
+      label: "Expected Behavior"
+      description: Please describe the results you expect
+      value: |
+        ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: os
+    attributes:
+      label: "OS / Environment"
+      value: |
+        Provide all relevant information below, e.g. target OS versions, network device firmware, etc.
+    validations:
+      required: true
+
+  - type: textarea
+    id: ansible
+    attributes:
+      label: "Ansible Version"
+      render: Shell
+      value: |
+        Paste verbatim output from "ansible --version" between quotes. This will be automatically formatted into code, so no need for backticks.
+    validations:
+      required: true
+
+  - type: textarea
+    id: collection
+    attributes:
+      label: "Collection Version"
+      render: Shell
+      value: |
+        Paste version of the collection. This will be automatically formatted into code, so no need for backticks.
+    validations:
+      required: true
+
+  - type: textarea
+    id: additional
+    attributes:
+      label: "Additional information"
+      description: Please add information like the used software versions, outputs of logs, OS information, screenshots, etc. to enhance the report
+      value: |
+        ...
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,55 @@
+---
+# reference: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests
+name: "Feature request"
+description: "Suggest an idea for this project."
+labels: [
+  "enhancement"
+]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Requesting a new feature or enhancement is following some simple rules:
+
+        - **Check**, if the feature is already requested
+        - **Describe** what your feature will bring to the community
+        - **Explain** the criteria to fulfill the request
+        - **Add** more details like mock ups, attachments, lists, screenshots
+        - **Follow Up** in the discussion to the feature
+
+  - type: textarea
+    id: description
+    attributes:
+      label: "Description"
+      description: Is your feature request related to a problem? Please describe.
+      placeholder: A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+    validations:
+      required: true
+
+  - type: textarea
+    id: solution
+    attributes:
+      label: "Solution"
+      description: Describe the solution you'd like
+      placeholder: A clear and concise description of what you want to happen.
+    validations:
+      required: false
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: "Alternatives"
+      description: Describe alternatives you've considered
+      placeholder: A clear and concise description of any alternative solutions or features you've considered.
+    validations:
+      required: false
+
+  - type: textarea
+    id: additional
+    attributes:
+      label: "Additional information"
+      description: Add any other context or screenshots about the feature request here.
+      value: |
+        ...
+    validations:
+      required: false

.github/labeler.yml

@@ -0,0 +1,7 @@
+---
+access_conf:
+  - changed-files:
+      - any-glob-to-any-file:
+          - roles/access_conf/**
+          - molecule/access_conf/**
+          - .github/workflows/access_conf.yml

.github/styles/config/vocabularies/Other/accept.txt

@@ -1,3 +1,7 @@
 BUG
 FIXME
 HACK
+bool|ean
+group_var
+host_var
+access_conf

.github/styles/config/vocabularies/Products/accept.txt

@@ -2,6 +2,9 @@
 (?i)Todo
 [Aa]nsible
 Active Directory
+(?i)git
+GitHub
 Jinja
 Kerberos
+Markdown
 Todo Tree

.github/workflows/ansible-lint.yml

@@ -0,0 +1,33 @@
+---
+name: Ansible Lint
+
+on:  # yamllint disable-line rule:truthy
+  # Run CI against all pushes (direct commits, also merged PRs), Pull Requests
+  push:
+    branches: ["main"]
+    paths:
+      - 'roles/**'
+      # - 'molecule/**'
+      # - 'requirements.txt'
+      - '.github/workflows/ansible-lint.yml'
+      - '.ansible-lint'
+  pull_request:
+    # The branches below must be a subset of the branches above
+    branches: ["main"]
+    paths:
+      - 'roles/**'
+      # - 'molecule/**'
+      # - 'requirements.txt'
+      - '.github/workflows/ansible-lint.yml'
+      - '.ansible-lint'
+
+jobs:
+  ansible-lint:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repo
+        uses: actions/checkout@v4
+
+      - name: Run ansible-lint
+        uses: ansible/ansible-lint@v24

.github/workflows/labeler.yml

@@ -0,0 +1,24 @@
+---
+name: "Pull Request Labeler"
+on:
+  pull_request_target:
+    types:
+      - assigned
+      - edited
+      - labeled
+      - opened
+      - reopened
+      - synchronize
+      - unlabeled
+
+jobs:
+  labeler:
+    permissions:
+      contents: read
+      pull-requests: write
+    if: github.repository == 'barstown/ansible-collection-server_baseline'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/labeler@v5
+        with:
+          repo-token: "${{ secrets.GITHUB_TOKEN }}"

CHANGELOG.md

@@ -1 +1,13 @@
 # Changelog
+
+## [1.0.0](https://github.com/barstown/ansible-collection-server_baseline/tree/1.0.0) (2024-06-18)
+
+[Full Changelog](https://github.com/barstown/ansible-collection-server_baseline/compare/0.0.1...1.0.0)
+
+**Implemented enhancements:**
+
+
+**Fixed bugs:**
+
+
+**Merged pull requests:**

CONTRIBUTING.md

@@ -0,0 +1,85 @@
+# Contributor guideline
+
+This document provides an overview of how you can participate in improving this project or extending it. We are grateful for all your help: bug reports and fixes, code contributions, documentation or ideas. Feel free to join, we appreciate your support!!
+
+## Communication
+
+### GitHub repositories
+
+Much of the issues, goals and ideas are tracked in the respective projects in GitHub. Please use this channel to report bugs and post ideas.
+
+## git and GitHub
+
+To contribute code please:
+
+1. Fork the project on GitHub
+2. Clone the project
+3. Add changes (and tests)
+4. Commit, sign off and push your changes
+5. Create a merge-request
+
+To have your code merged, see the expectations listed below.
+
+You can find a well-written guide [here](https://help.github.com/articles/fork-a-repo).
+
+Please follow common commit best-practices. Be explicit, have a short summary, a well-written description and references. This is especially important for the merge-request.
+
+Some great guidelines can be found [here](https://wiki.openstack.org/wiki/GitCommitMessages) and [here](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).
+
+## Expectations
+
+## Sign off your work
+
+The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project.
+[Here is the full text of the DCO](https://developercertificate.org/).
+Contributors must sign-off that they adhere to these requirements by adding a `Signed-off-by` line to commit messages.
+
+```text
+This is my commit message
+
+Signed-off-by: Random J Developer <random@developer.example.org>
+```
+
+Git even has a -s command line option to append this automatically to your commit message:
+
+```text
+git commit -s -m 'This is my commit message'
+```
+
+### Don't reinvent the wheel
+
+This project doesn't intend to reinvent the configuration stack for services. Aim to use official configuration projects first and provide extra functionality on top.
+
+- For Ansible check the [Ansible Module Index](http://docs.ansible.com/list_of_all_modules.html)
+
+### Be explicit
+
+- Please avoid using nonsensical property and variable names.
+- Use self-describing attribute names for user configuration.
+- In case of failures, communicate what happened and why a failure occurs to the user. Make it easy to track the code or action that produced the error. Try to catch and handle errors if possible to provide improved failure messages.
+
+### Add tests
+
+The security review of this project is done using integration tests.
+
+Whenever you add a new security configuration, please start by writing a test that checks for this configuration. For example: If you want to set a new attribute in a configuration file, write a test that expects the value to be set first. Then implement your change.
+
+You may add a new feature request by creating a test for whatever value you need.
+
+All tests will be reviewed internally for their validity and overall project direction.
+
+### Document your code
+
+As code is more often read than written, please provide documentation in all projects.
+
+### Follow coding styles
+
+We generally include test for coding guidelines:
+
+- Ansible is checked by running the playbook with the syntax-check option, for example `ansible-playbook foo.yml --syntax-check`
+
+Remember: Code is generally read much more often than written.
+
+### Use Markdown
+
+Wherever possible, please refrain from any other formats and stick to simple Markdown.

README.md

@@ -1,3 +1,30 @@
 # Ansible Collection - barstown.server_baseline
 
-Documentation for the collection.
+This collection aims to be the first tool in the box you reach for when
+configuring a server baseline.
+
+## Minimum required Ansible-version
+
+- Ansible >= 2.9.10
+
+## Included content
+
+- [access_conf](roles/access_conf/)
+
+In progress, not working:
+
+- More coming soon!
+
+## Installation
+
+
+Install the collection via ansible-galaxy:
+
+`ansible-galaxy collection install barstown.server_baseline`
+
+## Using this collection
+
+Please refer to the examples in the README file of the role.
+
+See [Ansible Using collections](https://docs.ansible.com/ansible/latest/user_guide/collections_using.html)
+for more details.