Skip to content

Commit

Permalink
Release 1.0.5 (#65)
Browse files Browse the repository at this point in the history
* 1.0.5-SNAPSHOT

* DMND-414: Remove DELETE methods from ngp-aa-osmt-osn

* DMND-519 Break up ElasticSearch reindexing into smaller transactions

* Renaming class to be more clear

* removed test file and secrets file
added nginx folder with two nginx files

* created node script file that finds kube files and replaces
template info with customer info

* templating the kube files
created a template placeholder on all necessary places to
deploy by client

* Fixed the grammar of the search result.  Used to say:
  2421 RSDs found based on and your filters. Viewing 1-50.

The 'and' has been moved inside the conditional, so it will only appear when there is something to 'and' with.

* Fixed bug: '1 collection' was sometimes '1 collections' (found through new test)

* Fixed bug: '1 RSD' was sometimes '1 RSDs' (found through new test)

* Removed osn pilot kube files

* added a new file called license (#4)

Added Apache 2.0 License

* added code of conduct file (#6)

* Contribution (#7)

* Created first draft of contribution file

* added link to issues and removed unecessary links

* Feature/multiple alignments (#8)

* ApiSkill.alignments is now has its own type: ApiAlignment instead of an ApiNamedReference

* OSMT-1217: support multiple alignments on create/edit skill form

* OSMT-1224: add 'framework' field to Keyword data model and 'isPartOf' field to ApiAlignment

* OSMT-1217: include alignment framework on create/edit skill form

* OSMT-1217:  dynamic alignment forms should contribute to overall form valid/pristine state

* OSMT-1219: display multiple alignments on Rich Skill Manage and published skill pages

* OSMT-1222: include all alignments in RichSkillCsvExport

* OSMT-1221: support multiple alignments in batch import

* OSMT-1221: batch import - unambiguous mapping for multiple alignments

* required form validation for Alignment name/URL

OSMT-1248

* update batch import template to include multiple alignments and framework

* sort alignments alphabetically by framework/skillName on manage/public lists

OSMT-1258

* update batch import property definitions copy for alignment name and framework

OSMT-1221

* Update copy for alignment name field

* add missing 's' to Alignments field label on published skill page

* final copy for alignment form fields

OSMT-1260

* backwards incompatible API changes necessitate a major version bump in the API spec.

* Create maven.yml

* Final repo check (#11)

Removed references to internals

* Updated build action

* Fixed Junit test case failure. (#13)

* Fixed Junit test case failure.

* Removed argument to skip test cases during build process from dockerfile & Readme.md

* added a clarifying statement under attribution (#17)

as per legal department, I have added the statement under
attribution about the contribution covenant.

* Update CONTRIBUTING.md (#22)

Updated contribution guidelines

* DMND-631 - Update code to include BLS JobCodes when the skills are im… (#26)

* DMND-631 - Update code to include BLS JobCodes when the skills are imported using the UI batch import process.

* DMND-631 - Addressed PR comments.

* DMND-673 Update open source repo with osmt tests (#29)

* DMND-674 Update open source repo with osmt-ui tests (#31)

* Test improvements (#32)

* * Added more tests
* Upgraded testing dependencies to support code coverage.

* Missed 2 files.

* * Removed isAuthorEditable() in many cases because the intent was separate from using the defaultAuthorValue, but was not coded separately.  i.e., if there is a defaultAuthorValue, then use it as the default. (#33)

* Fixed the assumption that the same web server is used for both UI and Service.  That's not always the case.
* Temporary handling of the ElasticSearch limitation of 10000 RSDs.  Until that is fixed by other means, we add a "+" to reduce confusion about the 10000 RSD count.

* Add noauth profile config for local development (#34)

* Add noauth profile config for local development

SecurityConfigNoAuth.kt taken from ngp-aa-osmt

* Add noauth profile config for local development

* Update readme (#9)

* added architectural diagram and BLS Onet import process

* added Okta steps for setup

* inserted PNG to assests folder to use in README file for the architectural diagram

* fixed png so that it removed the box with the osmt description.

* Closes #18 - Update README for community contributors (#39)

* Closes #18 - Update README for community contributors

also updated the API module's README

* Address review feedback for project README and docs

- also made a small tweak to .gitignore to support multiple env files.

* Readme formatting

* Add Testing Expections to CONTRIBUTING.md (#43)

* Add Testing Expections to CONTRIBUTING.md

- clarified the OSMT definition of unit test / integration test / e2e test

* Update CONTRIBUTING.md

Co-authored-by: drey-bigney <[email protected]>

* Adding test for ElasticSearchReindexer (#45)

* Fix issues with docker-compose (#41)

* Fix issues with docker-compose

- required changes in Dockerfile around yum install for certain openjdk version
- required skipping tests when building app Docker image because unit tests
  are mixed with integration tests that rely on Dockerized services
- fixed missinf fat jar functionality with UI as a dependency for API

* Update pom.xml

* Aadjust Dockerfile for review requests

- excluded defacto integration tests from Dockerfile mvn package with
  "dockerfile-build" Maven profile

* add new integration test to pom file for exclusions in docker build

* Feature/add code coverage (#46)

* * Added more tests
* Upgraded testing dependencies to support code coverage.

* Missed 2 files.

* * Added more tests.

* Added test for RichSkillSearchResultsComponent.  Also added support for ActivatedRouteStub.setQueryParams.

* Renamed ActivatedRouteStub.setParamsMap => setParams.

* Allow anonymous API acess to search and list endpoints for published skills and collections (#16)

* Support anonymous API usage of searching and listing for skills or collections.

allow for rate limiting public requests with bucket4j

* added a clarifying statement under attribution (#17)

as per legal department, I have added the statement under
attribution about the contribution covenant.

* Update CONTRIBUTING.md (#22)

Updated contribution guidelines

* DMND-631 - Update code to include BLS JobCodes when the skills are im… (#26)

* DMND-631 - Update code to include BLS JobCodes when the skills are imported using the UI batch import process.

* DMND-631 - Addressed PR comments.

* DMND-673 Update open source repo with osmt tests (#29)

* DMND-674 Update open source repo with osmt-ui tests (#31)

* Test improvements (#32)

* * Added more tests
* Upgraded testing dependencies to support code coverage.

* Missed 2 files.

* * Removed isAuthorEditable() in many cases because the intent was separate from using the defaultAuthorValue, but was not coded separately.  i.e., if there is a defaultAuthorValue, then use it as the default. (#33)

* Fixed the assumption that the same web server is used for both UI and Service.  That's not always the case.
* Temporary handling of the ElasticSearch limitation of 10000 RSDs.  Until that is fixed by other means, we add a "+" to reduce confusion about the 10000 RSD count.

* Add noauth profile config for local development (#34)

* Add noauth profile config for local development

SecurityConfigNoAuth.kt taken from ngp-aa-osmt

* Add noauth profile config for local development

* Update readme (#9)

* added architectural diagram and BLS Onet import process

* added Okta steps for setup

* inserted PNG to assests folder to use in README file for the architectural diagram

* fixed png so that it removed the box with the osmt description.

* Closes #18 - Update README for community contributors (#39)

* Closes #18 - Update README for community contributors

also updated the API module's README

* Address review feedback for project README and docs

- also made a small tweak to .gitignore to support multiple env files.

* Readme formatting

* Add Testing Expections to CONTRIBUTING.md (#43)

* Add Testing Expections to CONTRIBUTING.md

- clarified the OSMT definition of unit test / integration test / e2e test

* Update CONTRIBUTING.md

Co-authored-by: drey-bigney <[email protected]>

* Adding test for ElasticSearchReindexer (#45)

* Fix issues with docker-compose (#41)

* Fix issues with docker-compose

- required changes in Dockerfile around yum install for certain openjdk version
- required skipping tests when building app Docker image because unit tests
  are mixed with integration tests that rely on Dockerized services
- fixed missinf fat jar functionality with UI as a dependency for API

* Update pom.xml

* Aadjust Dockerfile for review requests

- excluded defacto integration tests from Dockerfile mvn package with
  "dockerfile-build" Maven profile

* add new integration test to pom file for exclusions in docker build

* Feature/add code coverage (#46)

* * Added more tests
* Upgraded testing dependencies to support code coverage.

* Missed 2 files.

* * Added more tests.

* Added test for RichSkillSearchResultsComponent.  Also added support for ActivatedRouteStub.setQueryParams.

* Renamed ActivatedRouteStub.setParamsMap => setParams.

* Support anonymous API usage of searching and listing for skills or collections.

allow for rate limiting public requests with bucket4j

* Rebase PR and update new test data

- also reverted change to MockData for how RSDs relate to
  connections

Co-authored-by: wgu-edwin <[email protected]>
Co-authored-by: John Kallies <[email protected]>
Co-authored-by: Roberto Meza <[email protected]>
Co-authored-by: Devon Sumner <[email protected]>
Co-authored-by: drey-bigney <[email protected]>

* Revert "Allow anonymous API acess to search and list endpoints for published skills and collections (#16)" (#53)

This reverts commit 4e34f7c.

* update Maven dependency (#54)

- update from 3.8.1 to 3.8.3
- 3.8.1 was no longer avaialble at the previous location. Aadded a more general URL

* update config changes for dev docker-compose deployment (#51)

* update config changes for dev docker-compose deployment

* add documentation covering dev stack and general config

* Updated readme for development stack configurations.
- Added details to set env variables
Added sample import files.

Co-authored-by: karan.singh <[email protected]>

* update README for Quickstart configs (#56)

* update config changes for docker-compose deployments

* update quickstart config changes for docker-compose deployments

* update README for Quickstart configs

* housekeeping for previous change

* Fixed to show this statement in italic.

* remove REINDEX_ELASTICSEARCH

* remove unused import in PropertyLogger

* remove orphaned code in docker_entrypoint script

* fix typo in docker volume path

* fix erroenous console message in docker_entrypoint script

* add FRONTEND_URL as env var in docker-compose.yml

* re-add REINDEX_ELASTICSEARCH in docker_entrypoint

Co-authored-by: karan.singh <[email protected]>

* Changes for import functionality. (#60)

* Changes for import functionality.

* Deleted the cmd to import skills.

Co-authored-by: Wiggins <[email protected]>
Co-authored-by: Cam Peterson <[email protected]>
Co-authored-by: campeterson22 <[email protected]>
Co-authored-by: Stirling Hale <[email protected]>
Co-authored-by: stirhale-wgu <[email protected]>
Co-authored-by: Edwin Santizo <[email protected]>
Co-authored-by: Devon Sumner <[email protected]>
Co-authored-by: Devon Sumner <[email protected]>
Co-authored-by: drey-bigney <[email protected]>
Co-authored-by: Drey Bigney <[email protected]>
Co-authored-by: wgu-edwin <[email protected]>
Co-authored-by: karan-beyond <[email protected]>
Co-authored-by: Roberto Meza <[email protected]>
Co-authored-by: karan.singh <[email protected]>
  • Loading branch information
15 people authored Oct 25, 2021
1 parent 4f82eec commit f3d4127
Show file tree
Hide file tree
Showing 148 changed files with 16,001 additions and 820 deletions.
25 changes: 25 additions & 0 deletions .github/workflows/maven.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
push:
branches: [ develop ]
pull_request:
branches: [ develop ]

jobs:
build:

runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v2
- name: Set up JDK 11
uses: actions/setup-java@v2
with:
java-version: '11'
distribution: 'adopt'
- name: Build with Maven
run: mvn -B package
2 changes: 2 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -23,3 +23,5 @@ build/

### VS Code ###
.vscode/

osmt*.env
92 changes: 92 additions & 0 deletions CODE-OF-CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# Code of Conduct

## Our Pledge

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of
experience, education, socio-economic status, nationality, personal appearance,
race, religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment
include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, or to ban temporarily or permanently any
contributor for other behaviors that they deem inappropriate, threatening,
offensive, or harmful.

## Scope

This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.

This Code of Conduct also applies outside the project spaces when the Project
Steward has a reasonable belief that an individual's behavior may have a
negative impact on the project or its community.

## Conflict Resolution

We do not believe that all conflict is bad; healthy debate and disagreement
often yield positive results. However, it is never okay to be disrespectful or
to engage in behavior that violates the project’s code of conduct.

If you see someone violating the code of conduct, you are encouraged to address
the behavior directly with those involved. Many issues can be resolved quickly
and easily, and this gives people more control over the outcome of their
dispute. If you are unable to resolve the matter for any reason, or if the
behavior is threatening or harassing, report it. We are dedicated to providing
an environment where participants feel welcome and safe.

Reports should be directed to [email protected]. All complaints will be reviewed
and investigated and will result in a response that is deemed necessary and
appropriate to the circumstances. The project team is obligated to maintain
confidentiality with regard to the reporter of an incident. Further details of
specific enforcement policies may be posted separately.

We will investigate every complaint, but you may not receive a direct response.
We will use our discretion in determining when and how to follow up on reported
incidents, which may range from not taking action to permanent expulsion from
the project and project-sponsored spaces. We will notify the accused of the
report and provide them an opportunity to discuss it before any action is taken.
The identity of the reporter will be omitted from the details of the report
supplied to the accused. In potentially harmful situations, such as ongoing
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,
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.
101 changes: 101 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
# 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 `[email protected]: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?
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.
24 changes: 6 additions & 18 deletions Dockerfile
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,9 @@
################
FROM centos:centos8.3.2011 as osmt-base

LABEL Maintainer="Francisco Gray, <[email protected]>"
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}
Expand All @@ -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
Expand All @@ -33,19 +32,12 @@ 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.3
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}

# 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/
ADD https://dlcdn.apache.org/maven/maven-3/${M2_VERSION}/binaries/apache-maven-${M2_VERSION}-bin.tar.gz /usr/share/src/

WORKDIR /usr/share/src

Expand All @@ -59,18 +51,14 @@ WORKDIR ${BASE_DIR}/build

USER ${USER}

RUN mvn clean package -Dmaven.test.skip.exec
# The dockerfile-build Maven profile excludes certain api integration tests that require access to the Docker service.
RUN mvn clean install -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}

COPY --from=build --chown=${USER}:${USER} ${BASE_DIR}/build/api/target/osmt-*.jar ${BASE_DIR}/bin/osmt.jar

ADD ./docker/ /${BASE_DIR}/
Expand Down
68 changes: 0 additions & 68 deletions Jenkinsfile

This file was deleted.

Loading

0 comments on commit f3d4127

Please sign in to comment.