By removing the explicit version from dropwizard-migrations in the POM, we'll inherit the one from kiwi-bom, which ensures all the various dropwizard-xxx dependencies are using the same version.

Fields:

• id
• startedAt
• endedAt
• status (RUNNING, COMPLETE, FAILED)
• failureOutput
• environment
• List of deploymentIds
• consolidatedChangeLog
• percentComplete

This issue was derived from a TODO in the AuthResource code:

// TODO: When the bundle is added, a cookie is setup in the response, need to figure out how to test
//       that the cookie is being set correctly. Currently response.getCookies() returns an empty map.
//       Probably need to figure out how to access/use the ContainerRequestContext in the test.

Need the following dao methods:

• insert (#103)
• findById
• findByCommitRefAndComponentIdentifier
• count (with filters on name and version) (#103)
• findBuildsByIds
• getBuilds (with paging and filters on name and version) (#103)

It should probably be configurable and have a default of something like 30 days?

This model will be used to track specific builds of a code distribution that will later be used for deployments and promotions. The model should contain the following attributes:

• id (Long)
• createdAt (Instant)
• released (boolean) Whether the build has been promoted to a non-dev environment
• repoNamespace (String)
• repoName (String)
• commitRef (String)
• commitUser (String)
• sourceBranch (String)
• componentIdentifier (String) e.g. service name or web app name
• componentVersion (String)
• distributionLocation (String) e.g. Link to Maven repo download

Admins will be able to do a few extra things like manage users and view audit records.

In BuildsPage.vue the following line:

<div v-for="line in props.value.split('\n')" v-bind:key="line" v-html="formatChangeLog(line, props.row)"/>

Fields:

• id
• createdAt
• createdBy
• message
• releaseTag
• environment
• status (PENDING, CONFIRMED, CANCELLED)
• List of buildIds
• releasePromotion (boolean)

i.e. models instead of core

          For later, you might as well create a simple Jupiter extension to do this before & after each test. Since you're going to need it in each resource test...

Originally posted by @sleberknight in #77 (comment)

          For sometime later, should we use `kiwi-parent` in this POM so that we inherit all these plugins. standard dependencies like JUnit, Mockito, etc.?

Originally posted by @sleberknight in #70 (comment)

Instead of it being a separate repo. This will aide in development and will allow for building docker containers

Need the following endpoints:

• GET /build (list all builds with paging and filtering)
• POST /build (registers a new build has completed in the system)

    Would you want to change some of these to be `record` types, since this service is using Java 17? Doing it now will probably be less pain than later, and we'll learn where the pain points are. I am pretty sure Jackson now supports records, less sure about other things and where those problems might arise. But, if we think records are the way to go in the future, especially for simple types like this, then maybe give them a try. One downside is we lose the builder, unless Lombok has made a builder for records somehow?

Originally posted by @sleberknight in #60 (comment)

          It would be nice if the Vue pages could (somehow) get the enum values dynamically, so they would not break if, for example, the enum changed. Is that something that could be done easily?

Originally posted by @sleberknight in #98 (review)

Fields:

• id
• buildId
• promotionId (once we have promotions)
• createdAt
• updatedAt
• deployedAt
• status (STAGED, IN_PROGRESS, COMPLETE, IGNORED, MANUAL, FAILED)
• environment

Build out OAuth options for:

• Google
• Github
• Gitlab

We should track whether the commit ref is from Github, Gitlab, others? so we can generate links back into those systems

Host

• id
• environment_id
• hostname
• description

Component

• id
• host_id
• name

We also will need a way to not have to hard code these if systems are using a cloud and hosts would be dynamic.

Right now the environments are only attached to the releases and tasks when the releases and tasks are created

• Create Models
• Create Daos
• Hook in to existing models and daos
• Update UI to account for new requirement