chore: update build and release assets.

.ansible-lint

@@ -0,0 +1,2 @@
+---
+profile: production

.cspell.json

@@ -0,0 +1,28 @@
+{
+  "ignorePaths": [
+    "**/node_modules/**",
+    "**/vscode-extension/**",
+    "**/.git/**",
+    "**/.pnpm-lock.json",
+    ".vscode",
+    "package-lock.json",
+    "megalinter-reports",
+    ".mega-linter.yml",
+    ".github/workflows/**",
+    ".github/*.md",
+    ".zenodo.json",
+    "AUTHORS.md",
+    "molecule/**",
+    "requirements*"
+  ],
+  "language": "en",
+  "version": "0.2",
+  "words": [
+    "zenodo",
+    "commitlint",
+    "griduser",
+    "gridusers",
+    "localusers",
+    "xrootd"
+  ]
+}

.github/CODE_OF_CONDUCT.md

@@ -76,7 +76,7 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the EGI Foundation team at [email protected]. The team will
+reported by contacting the EGI Foundation team at <[email protected]>. The team will
 review and investigate all complaints, and will respond in a way that it deems
 appropriate to the circumstances. The team is obligated to maintain
 confidentiality with regard to the reporter of an incident. Further details of

.github/CONTRIBUTING.md

@@ -7,8 +7,7 @@ Please take a few moments to read this short guide on how to contribute; bear in
 
 ## Feedback and Questions
 
-If you wish to discuss anything related to the project, please open an issue or start a topic on the [EGI Community Forum](https://community.egi.eu).
-The maintainers will sometimes move issues off of GitHub to the community forum if it is thought that longer, more open-ended discussion would be beneficial, including a wider community scope.
+If you wish to discuss anything related to the project, please open an issue.
 
 ## Kinds of contributions
 
@@ -17,41 +16,41 @@ The maintainers recognise that contributions can be made in many forms, dependin
 We undertake to identify these contributions through consensus-building and recognise them as formal contributions to the project where applicable.
 Contributions may come in the form of:
 
-  - Feature or documentation requests, where they describe a need or gap
-  - Authoring or review of releases
-  - Direct authorship of code or documentation
-  - Identifying and fixing bugs
+- Feature or documentation requests, where they describe a need or gap
+- Authoring or review of releases
+- Direct authorship of code or documentation
+- Identifying and fixing bugs
 
 ## Contribution Process
 
 Before proposing a contribution via pull request, please ensure that an issue is open describing the need for your contribution.
 You will need to refer to this issue number when you submit the pull request.
-  - **It is recommended to make pull requests against release candidate branches, whenever features are involved**, instead of against the master branch. See [Release Cycle](#release-cycle) below.
-  - Pull requests to the master branch can be made in the case obvious fixes. See [Obvious Fix Policy](#obvious-fix-policy)
+
+- **It is recommended to make pull requests against release candidate branches, whenever features are involved**, instead of against the master branch. See [Release Cycle](#release-cycle) below.
+- Pull requests to the master branch can be made in the case obvious fixes. See [Obvious Fix Policy](#obvious-fix-policy)
 
 We have a 3 step process for contributions.
 
-  1. Fork the project if you have not, and commit changes to a git branch
-  1. Create a GitHub Pull Request for your change, following the instructions in the pull request template.
-  1. Perform a [Code Review](#code-review-process) with the maintainers on the pull request.
+1. Fork the project if you have not, and commit changes to a git branch
+1. Create a GitHub Pull Request for your change, following the instructions in the pull request template.
+1. Perform a [Code Review](#code-review-process) with the maintainers on the pull request.
 
 ### Pull Request Requirements
 
-  1. **Explain your contribution in plain language.** To assist the maintainers in understanding and appreciating your pull request, please use the template to explain _why_ you are making this contribution, rather than just _what_ the contribution entails.
-  1. **This style guide is built to last.** We strive to ensure high quality and long-term applicability of the guide, ensuring that it stays up to date with the development of Ansible.
-  1. **Tests.** We expect tests to pass before peer review will begin.
-
+1. **Explain your contribution in plain language.** To assist the maintainers in understanding and appreciating your pull request, please use the template to explain _why_ you are making this contribution, rather than just _what_ the contribution entails.
+1. **This style guide is built to last.** We strive to ensure high quality and long-term applicability of the guide, ensuring that it stays up to date with the development of Ansible.
+1. **Tests.** We expect tests to pass before peer review will begin.
 
 ### Code Review Process
 
 Code review takes place in GitHub pull requests. See [this article](https://help.github.com/articles/about-pull-requests/) if you're not familiar with GitHub Pull Requests.
 
-Once you open a pull request, maintainers will review your code using the built-in code review process in Github PRs. The process at this point is as follows:
+Once you open a pull request, maintainers will review your code using the built-in code review process in GitHub PRs.
+The process at this point is as follows:
 
 1. A maintainer will review your code and merge it if no changes are necessary. Your change will be merged into the repository's `master` branch and will be noted in the project's `CHANGELOG.md` at the time of release.
 1. If want your contribution to motivate your inclusion in the authorship, please add a line to that effect in the pull request
-2. If a maintainer has feedback or questions on your changes they they will set `request changes` in the review and provide an explanation.
-
+1. If a maintainer has feedback or questions on your changes they they will set `request changes` in the review and provide an explanation.
 
 ### Obvious Fix Policy
 
@@ -60,16 +59,16 @@ Small contributions, such as fixing spelling errors, where the content is small
 As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. Assuming the change does not affect functionality, some common obvious fix examples include the following:
 
 - Spelling / grammar fixes
-- Typo correction, white space and formatting changes
+- Typo correction, whitespace and formatting changes
 - Comment clean up
-- Bug fixes that change default return values or error codes stored in constants
+- Bugfixes that change default return values or error codes stored in constants
 - Adding logging messages or debugging output
 - Changes to 'metadata' files like Gemfile, .gitignore, build scripts, etc.
 - Moving source files from one directory or package to another
 
 **Whenever you invoke the "obvious fix" rule, please say so in your commit message:**
 
-```
+```text
 ------------------------------------------------------------------------
 commit 370adb3f82d55d912b0cf9c1d1e99b132a8ed3b5
 Author: Julia Child <[email protected]>
@@ -84,17 +83,18 @@ Date:   Wed Sep 18 11:44:40 2015 -0700
 
 ## Using git
 
-For collaboration purposes, it is best if you create a GitHub account and fork the repository to your own account. Once you do this you will be able to push your changes to your GitHub repository for others to see and use, and it will be easier to send pull requests.
+For collaboration purposes, it is best if you create a GitHub account and fork the repository to your own account.
+Once you do this you will be able to push your changes to your GitHub repository for others to see and use, and it will be easier to send pull requests.
 
 ### Branches and Commits
 
-You should submit your patch as a git branch named after the Github issue, such as `#3`\. This is called a _topic branch_ and allows users to associate a branch of code with the ticket.
+You should submit your patch as a git branch named after the GitHub issue, such as `#3`.
+This is called a _topic branch_ and allows users to associate a branch of code with the ticket.
 
 It is a best practice to have your commit message have a _summary line_ that includes the ticket number, followed by an empty line and then a brief description of the commit. This also helps other contributors understand the purpose of changes to the code.
 
 ```text
     #3 - platform_family and style
-
     * use platform_family for platform checking
     * update notifies syntax to "resource_type[resource_name]" instead of
       resources() lookup
@@ -109,10 +109,10 @@ We follow the [Semantic Versioning](https://semver.org/) as far as applicable.
 This pattern says that software versions should take an `X.Y.Z` pattern where:
 
 - X is a major release, which may not be fully compatible with prior major releases
-- Y is a minor release, which adds both new features and bug fixes
-- Z is a patch release, which adds just bug fixes
+- Y is a minor release, which adds both new features and bugfixes
+- Z is a patch release, which adds just bugfixes
 
-Releases are generally performed after any bugfix / feature enhancement pull request merge. You can watch the Github repository for updates.
+Releases are generally performed after any bugfix / feature enhancement pull request merge. You can watch the GitHub repository for updates.
 The latest release will always point to the master branch, whilst release candidates will be done in version-specific branches, such as `v0.2.0-rc`.
 
 ### Publishing Releases
@@ -123,22 +123,14 @@ A `codemeta.json` must accompany each release accurately describing the research
 ## Contribution Do's and Don't's
 
 1. Please do include tests for your contribution.
-1. If you need help, ask on the [EGI Operations community](https://community.egi.eu/c/operations)
 1. Please do indicate new platform (families) or platform versions in the commit message, and update the relevant ticket.
-2. If a contribution adds new platforms or platform versions, indicate
-3. such in the body of the commit message(s), and update the relevant issues.
-4. When writing commit messages, it is helpful for others if you indicate the issue.
+1. If a contribution adds new platforms or platform versions, indicate
+1. such in the body of the commit message(s), and update the relevant issues.
+1. When writing commit messages, it is helpful for others if you indicate the issue.
 
 ## Community
 
-EGI benefits from a strong community of developers and system administrators, and vice-versa. If you have any questions or if you would like to get involved in the wider EGI community you can check out:
-
-- [EGI Community Forum](https://community.egi.eu/)
-- [EGI website](https://www.egi.eu)
-
-Also here are some additional pointers to some Ansible documentation:
+EGI benefits from a strong community of developers and system administrators, and vice-versa. If you have any questions or if you would like to get involved in the wider EGI community please contact EGI via the [EGI site](https://www.egi.eu/contact-us/)
 
-- [Ansible Docs](https://docs.ansible.com/ansible)
-- [Ansible Container Docs](https://docs.ansible.com/ansible-container)
 
 **This file has been modified from the Chef Cookbook Contributing Guide**.

.github/dependabot.yml

@@ -2,7 +2,11 @@
 version: 2
 updates:
   # Maintain dependencies for GitHub Actions
-  - package-ecosystem: "github-actions"
-    directory: "/"
+  - package-ecosystem: github-actions
+    directory: /
     schedule:
-      interval: "daily"
+      interval: weekly
+  - package-ecosystem: pip
+    directory: /
+    schedule:
+      interval: weekly

.github/workflows/check-links.yml

@@ -2,7 +2,7 @@
 name: Check links
 
 on: [push, pull_request]
-
+permissions: read-all
 jobs:
   markdown-link-check:
     name: Check links using markdown-link-check

.github/workflows/lint.yml

@@ -2,7 +2,7 @@
 name: Lint
 
 on: [push, pull_request]
-
+permissions: read-all
 jobs:
   super-lint:
     name: Lint with Super-Linter
@@ -17,12 +17,30 @@ jobs:
           fetch-depth: 0
 
       # Runs the Super-Linter action
-      - name: Run Super-Linter on new changes
-        uses: docker://ghcr.io/github/super-linter:slim-v4
+      # - name: Run Super-Linter on new changes
+      #   uses: docker://ghcr.io/github/super-linter:slim-v4
+      #   env:
+      #     DEFAULT_BRANCH: main
+      #     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      #     # Only check new or edited files
+      #     VALIDATE_ALL_CODEBASE: false
+      #     # Fail on errors
+      #     DISABLE_ERRORS: false
+      - name: MegaLinter
+        id: ml
+        uses: oxsecurity/[email protected]
         env:
-          DEFAULT_BRANCH: main
+          # All available variables are described in documentation
+          # https://megalinter.io/configuration/
+          VALIDATE_ALL_CODEBASE: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          # Only check new or edited files
-          VALIDATE_ALL_CODEBASE: false
-          # Fail on errors
-          DISABLE_ERRORS: false
+
+      # Upload MegaLinter artifacts
+      - name: Archive production artifacts
+        if: success() || failure()
+        uses: actions/[email protected]
+        with:
+          name: MegaLinter reports
+          path: |
+            megalinter-reports
+            mega-linter.log