Allow anonymous API acess to search and list endpoints for published skills and collections

.gitignore

@@ -24,4 +24,4 @@ build/
 ### VS Code ###
 .vscode/
 
-osmt.env
+osmt*.env

CODE-OF-CONDUCT.md

@@ -87,5 +87,6 @@ harassment or threats to anyone's safety, we may take action without notice.
 ## Attribution
 
 This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
-available at
-https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html,
+and it is licensed under the CC BY 4.0 License, the terms of which are available at
+https://creativecommons.org/licenses/by/4.0/legalcode.

CONTRIBUTING.md

@@ -1,53 +1,101 @@
-# Contributing to this repository
-
-## Getting started
-Make sure you follow the README to clone the project and setup
-
-## What do I need to know to help?
-
-If you are looking to help to with a code contribution our project uses Kotlin 1.3.72
-Angular Front-end 10.0 with Mysql DB, redis and Elasticsearch. If you don't feel ready to make a code contribution yet, no problem!
-Check out the [existing issues](https://github.com/wgu-opensource/osmt/issues) to see if an issue exists already for the change you
-want.
-
-## How do I make a contribution?
-Never made an open source contribution before? Wondering how contributions work in the in our project? Here's a quick rundown!
-
-1. Find an issue that you are interested in addressing, or a feature that you would like to add.
-
-2. Fork the repository associated with the issue to your local GitHub organization. This means that you will
-have a copy of the repository under **your-GitHub-username/repository-name**.
-
-3. Clone the repository to your local machine using **git clone https://github.com/wgu-opensource/osmt.git**
-or **git@github.com:wgu-opensource/osmt.git** for SSH.
-
-4. Create a new branch for your fix using **git checkout -b branch-name-here**. Note, make sure you branch of develop branch only!
-
-5. Make the appropriate changes for the issue you are trying to address, or the feature that you want to add.
-
-6. Use **git add insert-paths-of-changed-files-here** to add the file contents of the changed files to the "snapshot" git uses
-to manage the state of the project, also known as the index.
-
-7. Use **git commit -m "Insert a short message of the changes made here"** to store the contents of the index with a
-descriptive message.
-
-8. Push the changes to the remote repository using **git push origin branch-name-here**.
-
-9. Submit a pull request to the upstream repository.
-
-10. Title the pull request with a short description of the changes made and the issue or bug number associated with your change.
-For example, you can title an issue like so "Added more log outputting to resolve #4352".
-
-11. In the description of the pull request, explain the changes that you made, any issues you think exist with the pull request
-you made, and any questions you have for the maintainer. It's OK if your pull request is not perfect (no pull request is), the
-reviewer will be able to help you fix any problems and improve it!
-
-12. Wait for the pull request to be reviewed by a maintainer.
-
-13. Make changes to the pull request if the reviewing maintainer recommends them.
-
-14. Celebrate your success after your pull request is merged!
+# How to Contribute
+Never made an open source contribution before? Wondering how contributions work in our project? Here's a quick rundown!
+
+## Code of Conduct
+This project adheres to our [code of conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.
+
+## Issue Tracking
+We use GitHub's [Issue Tracker](https://github.com/wgu-opensource/osmt/issues).
+- You can submit issues for this project. Please do a courtesy search to verify that your issue is not already being tracked. If you have additional context for an existing issue, please add that with comments.
+- When you are looking for issues to work on, please notice if the issue already has an "Assignee". We are still developing how to manage ownership of a given issue.
+- Issues have labels describing what kind of changes are involved. GitHub search makes it easy to use these labels to find issues or pull requests you're interested in. Each label is listed with search links for finding open items with that label. We encourage you to read about other search filters to help you write more focused queries.
+
+- If you don't feel ready to make a code contribution yet, no problem! Check out the [existing issues](https://github.com/wgu-opensource/osmt/issues) to see if an issue exists already for the change you want.
+
+### Expectations for contributed code
+- OSMT project uses Kotlin 1.3.72 and Angular Front-end 10.0, with MySQL DB, redis and Elasticsearch. See the [Architecture](README.md#architecture) section in the README file.
+- Contributed code needs to follow appropriate style guides. Coding style isn't only a matter of preference, but is essential in managing an effective branching and release strategy. Trivial or unrelated code changes create merge conflicts, and introduce risk and wasted time in resolving them.
+  - Kotlin - https://developer.android.com/kotlin/style-guide
+  - Angular - https://angular.io/guide/styleguide
+- All code changes should be relevant to the issue/feature at hand. Avoid unrelated changes, like IDE import sorting or unrelated whitespace changes.
+  - Changes that are ["boy scouting"](https://headspring.com/2020/01/27/clean-code-conundrum/) (code improvements that leave an area cleaner than you found it) should be separate from feature changes. Boy scouting changes may be disruptive to others, and should be coordinated with project maintainers.
+- All execution paths for new code should be covered by unit tests.
+  - Many IDEs will report on unit test coverage and call out any gaps. That said, reporting of test coverage doesn't mean that the tests are useful or effective. If you find a section of code is difficult to unit test, this may indicate the need for some refactoring. Non-trivial refactors should also be coordinated with project maintainers.
+
+#### Testing expectations
+- The OSMT project embraces the [Test Pyramid](https://martinfowler.com/bliki/TestPyramid.html). Boiling this down:
+  - We want to test all execution paths with unit tests.
+    - Unit tests do not rely on any external services, network access, databases, or filesystem I/O, but rather use mocks when required. This also informs good object composition and design, facilitating healthy dependency injection/inversion of control.
+    - Unit test classes will be run by Maven in the "test" phase by the Surefire plugin, and need to end in "Test".
+  - We use integration tests as needed to stand up subsets of the application. These may require Docker containers or interactions between several components or services.
+    - Integration test classes will be run by Maven in the "verify" phase by the Failsafe plugin, and need to end in "IT". Failsafe has "pre-integration-test" and "post-integration-test" phases for standing up and tearing down integration test resources. The "post-integration-test" phase is always processed, regardless of test failures. This allows Maven to clean up and destroy integration test resources.
+  - We want to have as few E2E (end to end) tests as possible.
+    - Our E2E tests are implemented in Protractor as automated browser tests, and require walking through functionality on an actual OSMT instance. These are the most expensive and time-consuming tests. They are needed to ensure that layers of the application are wired up correctly, but should be used sparingly.
+
+## Release / Branching Strategy
+The OSMT project will follow the [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) model, with
+* Enhancement and bug fix work done on feature branches (```feature/branch-name```)
+* Feature branches merge into ```develop```, as the integration branch
+* Releases are cut from ```develop``` (as ```release-branch-name```), and merged back in to both ```master``` and ```develop```
+>
+
+### Using git with this project
+1. Use the project's [Issue Tracker](https://github.com/wgu-opensource/osmt/issues) to find an issue that you want to address, or a feature that you would like to add.
+2. Clone the repository to your local machine using `git clone https://github.com/wgu-opensource/osmt.git` or `git@github.com:wgu-opensource/osmt.git` for SSH.
+3. Create a new branch for your fix using `git checkout origin/develop -b your-local-branch-name`.
+   - Note, make sure you only branch from `origin/develop`!
+4. Make the appropriate changes for the issue you are trying to address, or the feature that you want to add. Include appropriate test coverage.
+5. Use `git add insert-paths-of-changed-files-here` to stage the changed files for the commit.
+6. Use `git commit` to commit the contents of the index. This should open an editor; please provide a useful commit message (see below for [more about commit messages](#commit-message-format))
+7. On GitHub, OSMT uses a branching workflow, where committers create a feature branch containing the desired changes (rather than asking contributors to fork our GitHub repo). Push the changes to a feature branch in GitHub using `git push HEAD:origin feature/your-feature-branch-name`.
+  - A given branch should only have a single feature. Multiple unrelated features should handled by creating multiple feature branches.
+
+### Submit a Pull Request (PR)
+A ["Pull Request"](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) initiates a code review workflow in which OSMT project maintainers review your contributed code, and request additional changes or approve it for merging into a coming release.
+1. After pushing your commit to a feature branch on GitHub, please review it for any unexpected changes. When you are ready for a review, you can submit a pull request (GitHub will provide a button for this in the browser after you push).
+   - Provide a title for your pull request. It can be the same as the 1st line of your commit message.
+   - Provide a description for your pull request. It can be the same as the description in your commit message.
+   - It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it!
+2. Wait for the pull request to be reviewed by a maintainer.
+3. Make changes to the pull request if the reviewing maintainer recommends them. Push those changes to the same GitHub feature branch.
+4. Celebrate your success after your pull request is merged!
+
+### Commit Message Format
+Please format your commit messages with a summary line (50 characters or less), a blank line, and more detailed text explaining the commit.
+- Understand ahead of time that commits are often squashed, so commit messages may not last forever.
+- Speak to both others and your near-future self. Capture enough ephemeral context to understand why this commit exists.
+- Reference [GitHub issues](https://guides.github.com/features/issues/) whenever possible.
+
+#### Example commit message:
+_(with thanks to https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)_
+```
+Capitalized, short (50 chars or less) summary #
+
+More detailed explanatory text, if necessary.  Wrap it to about 72
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); tools like rebase can get confused if you run the
+two together.
+
+Write your summary line in the imperative: "Fix bug" and not "Fixed bug"
+or "Fixes bug."  This convention matches up with commit messages generated
+by commands like git merge and git revert.
+
+Further paragraphs come after blank lines.
+
+- Bullet points are okay, too
+
+- Typically a hyphen or asterisk is used for the bullet, followed by a
+  single space, with blank lines in between, but conventions vary here
+
+- Use a hanging indent
+```
+
+### Tips
+- Keep changes small and focused. In the case of multiple bug fixes or unrelated features, create one branch and PR per feature. This makes it easier to review, merge, and potentially rollback changes.
+- Avoid unrelated code changes, even in a changed file. Imports and whitespace formatting are frequent unrelated changes.
+- Test coverage, test coverage, test coverage. 
 
 # Where can I go for help?
-If you need help, you can ask questions on our mailing list, IRC chat, or
-[list any other communication platforms that your project uses].
+Make sure you follow the README to clone the project and setup. If you need help, you can ask questions in our GitHub '[Discussions](https://github.com/wgu-opensource/osmt/discussions)' area.

Dockerfile

@@ -6,7 +6,6 @@ FROM centos:centos8.3.2011 as osmt-base
 LABEL Maintainer="WGU / OSN"
 LABEL Version="1.0"
 
-ENV JAVA_VERSION=11.0.9.11
 ENV JAVA_HOME=/etc/alternatives/jre
 ENV USER=osmt
 ENV BASE_DIR=/opt/${USER}
@@ -15,7 +14,7 @@ ENV BASE_DIR=/opt/${USER}
 RUN /usr/bin/yum install -y epel-release \
     && /usr/bin/yum update -y \
     && /usr/bin/yum remove -y java-1.8.0-openjdk* \
-    && /usr/bin/yum install -y curl java-11-openjdk-headless-${JAVA_VERSION} wget
+    && /usr/bin/yum install -y curl java-11-openjdk wget
 
 # Add in configuration files
 ADD ./docker/etc /etc
@@ -34,15 +33,14 @@ RUN /usr/sbin/useradd -r -d ${BASE_DIR} -s /bin/bash ${USER} -k /etc/skel -m -U
 FROM osmt-base as build
 
 ENV JAVA_HOME=/etc/alternatives/jre
-ENV JAVA_VERSION=11.0.9.11
-ENV M2_VERSION=3.6.3
+ENV M2_VERSION=3.8.1
 ENV M2_HOME=/usr/local/maven
 ENV PATH=${M2_HOME}/bin:${PATH}
 ENV USER=osmt
 ENV BASE_DIR=/opt/${USER}
 
 # Install OpenJDK Development Packages
-RUN /usr/bin/yum install -y java-11-openjdk-devel-${JAVA_VERSION}
+RUN /usr/bin/yum install -y java-11-openjdk-devel
 
 # Download / Install Maven
 ADD https://www-eu.apache.org/dist/maven/maven-3/${M2_VERSION}/binaries/apache-maven-${M2_VERSION}-bin.tar.gz /usr/share/src/
@@ -59,15 +57,15 @@ WORKDIR ${BASE_DIR}/build
 
 USER ${USER}
 
-RUN mvn clean package
+# The dockerfile-build Maven profile excludes certain api integration tests that require access to the Docker service.
+RUN mvn clean package -P dockerfile-build
 
 ######################
 ### PACKAGING IMAGE ##
 ######################
 FROM osmt-base
 
 ENV JAVA_HOME=/etc/alternatives/jre
-ENV JAVA_VERSION=11.0.9.11
 ENV USER=osmt
 ENV BASE_DIR=/opt/${USER}