Add auth to argo (#1249)

* Mdformat tables (#1186)

* Add mdformat-tables

* Run mdformat on all files

* mdformat only docs folder (restore .github md files)

* Fix some vale, restore README/RELEASE

* [ImgBot] Optimize images (#1187)

/docs/source/images/dev_postman_for_keycloak.png -- 298.79kb -> 270.60kb (9.44%)

Signed-off-by: ImgBotApp <ImgBotHelp@gmail.com>

Co-authored-by: ImgBotApp <ImgBotHelp@gmail.com>

* Bump conda-store version to 0.3.14 (#1192)

* Allow terraform init to upgrade providers within version specification (#1194)

* Allow terraform init to upgrade providers within version specification

Closes #1193

* Black formatting

* Adding missing __init__ files (#1196)

* Adding missing __init__ files

Closes #1195

* Explicitely using qhub for package

* Give hint on what to include

* Release 0.3.15 for Conda-Store (#1205)

* Profilegroups (#1203)

* Fix in case groups is None

* access all/keycloak/yaml

* jupyterlabproflies mapper

* Keycloak profiles working

* ignore changes to keycloak group attributes

* qhub upgrade for jupyterlab profiles

* docs for jupyterlabprofiles

* Renamed to jupyterlab_profiles

* Render `.gitignore`, black py files (#1206)

* Render .gitignore

* Render clean .gitignore

* Add unit test

* Upgrade black

* Upgrade black

* black format

* exclude qhub/_version.py from black

* Black what needs blackening

* Fix

* Fix

* Update qhub-dask version (#1224)

* Fix env doc links and add corresponding tests (#1216)

* Fix env doc links and add corresponding tests

* fix broken image link

* fix black formatting

* map(any) -> any (#1213)

* Update release notes - justification for changes in `v0.4.0`  (#1178)

* Update release notes

* Remove ref to cookiecutter

* Update link-checker version

* Fix

* Use lycee link-checker instead

* Remove lycee, update md config.json

* Revert version

* Release notes cleanup

* Rewording

* Add to vocab

* Fix table

* Add explicit warning about release

* Update README.md

Fixed some syntax/grammar issues.

* Minor updates

Co-authored-by: Christopher Ostrouchov <chris.ostrouchov@gmail.com>
Co-authored-by: Shannon <magsol@gmail.com>

* Merge spawner and profile env vars

* Support for pinning the IP address of the load balancer via terraform overrides (#1235)

* Suport adding load balancer annotations and ip via terraform overrides

* add documentation for terraform overrides

* make terraform overrides being able to override any variable

* Bump moment from 2.29.1 to 2.29.2 in /tests_e2e (#1241)

Bumps [moment](https://github.com/moment/moment) from 2.29.1 to 2.29.2.
- [Release notes](https://github.com/moment/moment/releases)
- [Changelog](https://github.com/moment/moment/blob/develop/CHANGELOG.md)
- [Commits](moment/moment@2.29.1...2.29.2)

---
updated-dependencies:
- dependency-name: moment
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Update cdsdashboards to 0.6.1, Voila to 0.3.5 (#1240)

* Update cdsdashboards to 0.6.1

* voila v0.3.5

* Bump minimist from 1.2.5 to 1.2.6 in /tests_e2e (#1208)

Bumps [minimist](https://github.com/substack/minimist) from 1.2.5 to 1.2.6.
- [Release notes](https://github.com/substack/minimist/releases)
- [Commits](https://github.com/substack/minimist/compare/1.2.5...1.2.6)

---
updated-dependencies:
- dependency-name: minimist
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* output check fix (#1244)

Co-authored-by: Adam-D-Lewis <>

* Add auth to argo

* add argo_workflows value to qhub init command

* update black version

* update black in setup.cfg

Co-authored-by: Dan Lester <dan@ideonate.com>
Co-authored-by: imgbot[bot] <31301654+imgbot[bot]@users.noreply.github.com>
Co-authored-by: ImgBotApp <ImgBotHelp@gmail.com>
Co-authored-by: Christopher Ostrouchov <chris.ostrouchov@gmail.com>
Co-authored-by: Amit Kumar <dtu.amit@gmail.com>
Co-authored-by: Shannon <magsol@gmail.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Adam Lewis <23342526+Adam-D-Lewis@users.noreply.github.com>
Co-authored-by: Adam-D-Lewis <>

.github/workflows/markdown.links.config.json

@@ -21,5 +21,10 @@
     {
         "pattern": "https://cloud.google.com"
     }
-	]
+	],
+    "timeout": "20s",
+    "retryOn429": true,
+    "retryCount": 5,
+    "fallbackRetryDelay": "30s",
+    "aliveStatusCodes": [200, 206]
 }

.github/workflows/test.yaml

@@ -46,8 +46,8 @@ jobs:
       - name: Black Formatting
         run: |
           black --version
-          black qhub --diff
-          black --check qhub
+          black qhub --diff --exclude "qhub/_version.py"
+          black --check qhub --exclude "qhub/_version.py"
       - name: Flake8 Formatting
         run: |
           flake8 --version

.gitignore

@@ -46,4 +46,4 @@ qhub-config.yaml
 .vscode/
 
 # Ignore Vale
-vale
+./vale

.pre-commit-config.yaml

@@ -34,6 +34,7 @@ repos:
     rev: 0.7.13
     hooks:
     - id: mdformat
+      files: ^docs/
       name: mdformat
       description: "CommonMark compliant Markdown formatter"
       entry: mdformat
@@ -44,3 +45,5 @@ repos:
       language_version: python3
       types: [markdown]
       minimum_pre_commit_version: '1.0.0'
+      additional_dependencies:
+      - mdformat-tables

CONTRIBUTING.md

@@ -1,10 +1,9 @@
 # Contributing to QHub
 
-:sparkles: :raised_hands:  Welcome to the QHub repository! :sparkles: :raised_hands:
+:sparkles: :raised_hands: Welcome to the QHub repository! :sparkles: :raised_hands:
 
-Everyone is welcome to contribute, and we value everybody's contribution. Code is not the only way to help the community.
-Your choices aren't limited to programming; as you can see below, there are many areas where we need **your** help.
-Answering questions, helping others, reaching out and improving the documentation is immensely valuable to the community.
+Everyone is welcome to contribute, and we value everybody's contribution. Code is not the only way to help the community. Your choices aren't limited to programming; as you can see
+below, there are many areas where we need **your** help. Answering questions, helping others, reaching out and improving the documentation is immensely valuable to the community.
 
 Whichever way you choose to contribute, please be mindful of respecting our code of conduct.
 
@@ -27,54 +26,53 @@ This document will help you through your journey of open source. Here, you'll ge
 
 ## 🏷 Where to start: issues
 
-Before you open a new issue, please check the [open issues][QHub-issues]. See if the issue has already been reported or if your idea has already been discussed.
-If so, it's often better to leave a comment on a current issue rather than opening a new one. Old issues also often include helpful tips and solutions to common problems.
+Before you open a new issue, please check the [open issues][qhub-issues]. See if the issue has already been reported or if your idea has already been discussed. If so, it's often
+better to leave a comment on a current issue rather than opening a new one. Old issues also often include helpful tips and solutions to common problems.
 
-If you are looking for specific help with QHub or its configuration, check our [Github discussions][QHub-qa].
+If you are looking for specific help with QHub or its configuration, check our [Github discussions][qhub-qa].
 
 ### Submitting issues
 
-When opening an issue, give it a **descriptive title** and provide as much information as possible.
-Our [issue templates][QHub-templates] help you remember the most important details to include.
+When opening an issue, give it a **descriptive title** and provide as much information as possible. Our [issue templates][qhub-templates] help you remember the most important
+details to include.
 
 There are three issues templates to choose from:
 
 1. **Bug Report**: With this template, create an issue report that can help others fix something currently broken.
 2. **Documentation**: Use this template to provide feedback on our documentation or suggest additions and improvements.
-3. **Feature request**: Is there anything to make the community work better? Have you spotted something missing in QHub?
-  Use this template to share your feature ideas with the QHub team.
+3. **Feature request**: Is there anything to make the community work better? Have you spotted something missing in QHub? Use this template to share your feature ideas with the QHub
+   team.
 
 A few more tips:
 
-- **Describing your issue**: Try to provide as many details as possible. What exactly goes wrong? How is it failing? Is there an error?
-  "XY doesn't work" usually isn't that helpful for tracking down problems. Always remember to include the code you ran, and if possible,
-  extract only the relevant parts, and don't dump your entire script.
-  This will make it easier for us to reproduce the error. Screenshots are also great ways to demonstrate errors or unexpected behaviours.
+- **Describing your issue**: Try to provide as many details as possible. What exactly goes wrong? How is it failing? Is there an error? "XY doesn't work" usually isn't that helpful
+  for tracking down problems. Always remember to include the code you ran, and if possible, extract only the relevant parts, and don't dump your entire script. This will make it
+  easier for us to reproduce the error. Screenshots are also great ways to demonstrate errors or unexpected behaviours.
 
-- **Sharing long blocks of code or logs**: If you need to include extended code, logs or tracebacks, you can wrap them in `<details> and </details>`.
-  This collapses the content, so it only becomes visible on click, making it easier to read and follow.
+- **Sharing long blocks of code or logs**: If you need to include extended code, logs or tracebacks, you can wrap them in `<details> and </details>`. This collapses the content, so
+  it only becomes visible on click, making it easier to read and follow.
 
 - **Suggesting a new feature:** When suggesting a new feature, please also add details on how this new feature might impact the users' and developers' workflow.
 
 ### Issue labels
 
-Check our [labels page][QHub-labels] for an overview of the system we use to tag our issues and pull requests.
+Check our [labels page][qhub-labels] for an overview of the system we use to tag our issues and pull requests.
 
 ## :computer: Contributing to the codebase
 
-You don't have to be a Python or Kubernetes pro to contribute, and we're happy to help you get started.
-If you're new to QHub, an excellent place to start are the issues marked with the [type: good first issue](https://github.com/Quansight/QHub/labels/type%3A%20good%20first%20issue) label,
-which we use to tag bugs and feature requests that require low-effort (i.e. low entry-barrier or little in-depth knowledge needed) and self-contained.
-If you've decided to take on one of these problems and you're making good progress, don't forget to add a quick comment to the issue to assign this to yourself.
-You can also use the issue to ask questions or share your work in progress.
+You don't have to be a Python or Kubernetes pro to contribute, and we're happy to help you get started. If you're new to QHub, an excellent place to start are the issues marked
+with the [type: good first issue](https://github.com/Quansight/QHub/labels/type%3A%20good%20first%20issue) label, which we use to tag bugs and feature requests that require
+low-effort (i.e. low entry-barrier or little in-depth knowledge needed) and self-contained. If you've decided to take on one of these problems and you're making good progress,
+don't forget to add a quick comment to the issue to assign this to yourself. You can also use the issue to ask questions or share your work in progress.
 
 ### Development process - short summary
 
 Never made an open-source contribution before? Wondering how contributions work in the QHub world? Here's a quick rundown!
 
 #### If you are a first-time contributor
 
-1. Go to the [QHub repository][QHub-repo] and click the `fork` button on the top-right corner to create your own copy of the project.
+1. Go to the [QHub repository][qhub-repo] and click the `fork` button on the top-right corner to create your own copy of the project.
+
 2. Clone the project to your local computer:
 
    ```bash
@@ -101,6 +99,7 @@ Now using the command `git remote -v` will show two remote repositories:
 #### Develop your contribution
 
 1. Find an issue you are interested in addressing or a feature you would like to address.
+
 2. Pull the latest changes from upstream
 
    ```bash
@@ -116,58 +115,59 @@ Now using the command `git remote -v` will show two remote repositories:
    # this is an alternative to the git checkout -b feature/<feature name> command
    ```
 
-4. Commit locally as you progress (`git add` and `git commit`). Use an adequately formatted commit message,
-   write tests that fail before your change and pass afterwards, run all the tests locally. Be sure to document any changed behaviour in docstrings.
+4. Commit locally as you progress (`git add` and `git commit`). Use an adequately formatted commit message, write tests that fail before your change and pass afterwards, run all
+   the tests locally. Be sure to document any changed behaviour in docstrings.
 
 #### Submitting your contribution
 
 1. Push your changes back to your fork on GitHub:
 
-    ```bash
-    git push origin feature/<feature name>
-    ```
+   ```bash
+   git push origin feature/<feature name>
+   ```
 
 2. Enter your GitHub username and password (repeat contributors or advanced users can remove this step by connecting to GitHub with SSH).
-3. Go to GitHub. The new branch will show a green **Pull Request** button. Make sure the title and message are clear, concise, and self-explanatory.
-   Then click the button to submit it.
 
-:warning: - If your commit introduces a new feature or changes functionality,  please
-ensure you first create an open Pull Request on our repo with `WIP` (work in progress) in the title and marked as draft, explaining what you want to do.
-That way we can discuss it
-to be sure it makes sense for QHub. Or start by creating an issue and indicate that you would be interested in solving the problem yourself.
-This is generally not necessary for bug fixes, documentation updates, etc. However, if you do not get any reaction, do feel free to ask for a review.
+3. Go to GitHub. The new branch will show a green **Pull Request** button. Make sure the title and message are clear, concise, and self-explanatory. Then click the button to submit
+   it.
+
+:warning: - If your commit introduces a new feature or changes functionality, please ensure you first create an open Pull Request on our repo with `WIP` (work in progress) in the
+title and marked as draft, explaining what you want to do. That way we can discuss it to be sure it makes sense for QHub. Or start by creating an issue and indicate that you would
+be interested in solving the problem yourself. This is generally not necessary for bug fixes, documentation updates, etc. However, if you do not get any reaction, do feel free to
+ask for a review.
 
 #### Review process
 
-Reviewers (the other developers and interested community members) will write inline and/or general comments on your Pull Request (PR) to help you improve its implementation, documentation and style.
-Every developer working on the project has their code reviewed, and we've come to see it as a friendly conversation from which we all learn and the overall code quality benefits.
-Therefore, please don't let the review discourage you from contributing: its only aim is to improve the quality of the project, not to criticize
-(we are, after all, very grateful for the time you're donating!).
+Reviewers (the other developers and interested community members) will write inline and/or general comments on your Pull Request (PR) to help you improve its implementation,
+documentation and style. Every developer working on the project has their code reviewed, and we've come to see it as a friendly conversation from which we all learn and the overall
+code quality benefits. Therefore, please don't let the review discourage you from contributing: its only aim is to improve the quality of the project, not to criticize (we are,
+after all, very grateful for the time you're donating!).
 
-To update your PR, make your changes on your local repository, commit, run tests, and only if they succeed, push to your fork.
-The PR will update automatically as soon as those changes are pushed up (to the same branch as before).
-If you have no idea how to fix the test failures, you may push your changes anyway and ask for help in a PR comment.
+To update your PR, make your changes on your local repository, commit, run tests, and only if they succeed, push to your fork. The PR will update automatically as soon as those
+changes are pushed up (to the same branch as before). If you have no idea how to fix the test failures, you may push your changes anyway and ask for help in a PR comment.
 
-Various continuous integration (CI) pipelines are triggered after each PR update to build artefacts, run unit tests, and check the coding style of your branch.
-The CI tests must pass before your PR can be merged. If CI fails, you can find why by clicking on the "failed" icon (red cross) and inspecting the build and test log.
-To avoid overuse and waste of this resource, test your work locally before committing.
+Various continuous integration (CI) pipelines are triggered after each PR update to build artefacts, run unit tests, and check the coding style of your branch. The CI tests must
+pass before your PR can be merged. If CI fails, you can find why by clicking on the "failed" icon (red cross) and inspecting the build and test log. To avoid overuse and waste of
+this resource, test your work locally before committing.
 
 Before merging, a PR must be approved by at least one core team member. Approval means the core team member has carefully reviewed the changes, and the PR is ready for merging.
 
 #### Document changes
 
-Beyond changes to a functions docstring and possible description in the general documentation, if your change introduces any user-facing modifications, they may need to be mentioned in the release notes.
+Beyond changes to a functions docstring and possible description in the general documentation, if your change introduces any user-facing modifications, they may need to be
+mentioned in the release notes.
 
 #### Cross referencing issues
 
-If the PR relates to any issues, you can add the text `xref gh-xxxx` where `xxxx` is the issue number to GitHub comments. Likewise, if the PR solves an issue, replace the `xref` with `closes`, `fixes` or any other flavours [github accepts](https://help.github.com/en/articles/closing-issues-using-keywords).
+If the PR relates to any issues, you can add the text `xref gh-xxxx` where `xxxx` is the issue number to GitHub comments. Likewise, if the PR solves an issue, replace the `xref`
+with `closes`, `fixes` or any other flavours [github accepts](https://help.github.com/en/articles/closing-issues-using-keywords).
 
 In the source code, be sure to preface any issue or PR reference with gh-xxxx.
 
 <!-- Links -->
-[QHub-repo]: https://github.com/Quansight/QHub/
-[QHub-issues]: https://github.com/Quansight/QHub/issues
-[QHub-labels]: https://github.com/Quansight/QHub/labels
-[QHub-templates]: https://github.com/Quansight/QHub/issues/new/choose
-[QHub-qa]: https://github.com/Quansight/QHub/discussions/categories/q-a
-[issue-template]: https://github.com/Quansight/QHub/blob/main/ISSUE_TEMPLATE.md
+
+[qhub-issues]: https://github.com/Quansight/QHub/issues
+[qhub-labels]: https://github.com/Quansight/QHub/labels
+[qhub-qa]: https://github.com/Quansight/QHub/discussions/categories/q-a
+[qhub-repo]: https://github.com/Quansight/QHub/
+[qhub-templates]: https://github.com/Quansight/QHub/issues/new/choose