pact_broker 2.89.1 → 2.90.0

data/.rubocop.yml

@@ -1,314 +0,0 @@
-require:
-  - rubocop-performance
-
-AllCops:
-  DisabledByDefault: true
-
-Lint/AmbiguousOperator:
-  Description: >-
-                 Checks for ambiguous operators in the first argument of a
-                 method invocation without parentheses.
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#parens-as-args'
-  Enabled: true
-
-Lint/AmbiguousRegexpLiteral:
-  Description: >-
-                 Checks for ambiguous regexp literals in the first argument of
-                 a method invocation without parenthesis.
-  Enabled: true
-
-Layout/IndentationWidth:
-  Enabled: true
-
-Lint/Syntax:
-  Enabled: true
-
-Lint/AssignmentInCondition:
-  Description: "Don't use assignment in conditions."
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#safe-assignment-in-condition'
-  Enabled: true
-
-Layout/BlockAlignment:
-  Description: 'Align block ends correctly.'
-  Enabled: true
-
-Lint/CircularArgumentReference:
-  Description: "Don't refer to the keyword argument in the default value."
-  Enabled: true
-
-Layout/ConditionPosition:
-  Description: >-
-                 Checks for condition placed in a confusing position relative to
-                 the keyword.
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#same-line-condition'
-  Enabled: true
-
-Lint/Debugger:
-  Description: 'Check for debugger calls.'
-  Enabled: true
-
-Layout/DefEndAlignment:
-  Description: 'Align ends corresponding to defs correctly.'
-  Enabled: true
-
-Lint/DeprecatedClassMethods:
-  Description: 'Check for deprecated class method calls.'
-  Enabled: true
-
-Lint/DuplicateMethods:
-  Description: 'Check for duplicate methods calls.'
-  Enabled: true
-
-Lint/EachWithObjectArgument:
-  Description: 'Check for immutable argument given to each_with_object.'
-  Enabled: true
-
-Lint/ElseLayout:
-  Description: 'Check for odd code arrangement in an else block.'
-  Enabled: true
-
-Lint/EmptyEnsure:
-  Description: 'Checks for empty ensure block.'
-  Enabled: true
-
-Lint/EmptyInterpolation:
-  Description: 'Checks for empty string interpolation.'
-  Enabled: true
-
-Layout/EndAlignment:
-  Description: 'Align ends correctly.'
-  Enabled: true
-
-Lint/EnsureReturn:
-  Description: 'Do not use return in an ensure block.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#no-return-ensure'
-  Enabled: true
-
-Security/Eval:
-  Description: 'The use of eval represents a serious security risk.'
-  Enabled: true
-
-Lint/FormatParameterMismatch:
-  Description: 'The number of parameters to format/sprint must match the fields.'
-  Enabled: true
-
-Lint/SuppressedException:
-  Description: "Don't suppress exception."
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#dont-hide-exceptions'
-  Enabled: true
-
-Lint/LiteralAsCondition:
-  Description: 'Checks of literals used in conditions.'
-  Enabled: true
-
-Lint/LiteralInInterpolation:
-  Description: 'Checks for literals used in interpolation.'
-  Enabled: true
-
-Lint/Loop:
-  Description: >-
-                 Use Kernel#loop with break rather than begin/end/until or
-                 begin/end/while for post-loop tests.
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#loop-with-break'
-  Enabled: true
-
-Lint/NestedMethodDefinition:
-  Description: 'Do not use nested method definitions.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#no-nested-methods'
-  Enabled: true
-
-Lint/NonLocalExitFromIterator:
-  Description: 'Do not use return in iterator to cause non-local exit.'
-  Enabled: true
-
-Lint/ParenthesesAsGroupedExpression:
-  Description: >-
-                 Checks for method calls with a space before the opening
-                 parenthesis.
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#parens-no-spaces'
-  Enabled: true
-
-Lint/RequireParentheses:
-  Description: >-
-                 Use parentheses in the method call to avoid confusion
-                 about precedence.
-  Enabled: true
-
-Lint/RescueException:
-  Description: 'Avoid rescuing the Exception class.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#no-blind-rescues'
-  Enabled: true
-
-Lint/ShadowingOuterLocalVariable:
-  Description: >-
-                 Do not use the same name as outer local variable
-                 for block arguments or block local variables.
-  Enabled: true
-
-Lint/RedundantStringCoercion:
-  Description: 'Checks for Object#to_s usage in string interpolation.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#no-to-s'
-  Enabled: true
-
-Lint/UnderscorePrefixedVariableName:
-  Description: 'Do not use prefix `_` for a variable that is used.'
-  Enabled: true
-
-Lint/RedundantCopDisableDirective:
-  Description: >-
-                 Checks for rubocop:disable comments that can be removed.
-                 Note: this cop is not disabled when disabling all cops.
-                 It must be explicitly disabled.
-  Enabled: true
-
-Lint/UnusedBlockArgument:
-  Description: 'Checks for unused block arguments.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#underscore-unused-vars'
-  Enabled: true
-
-Lint/UnusedMethodArgument:
-  Description: 'Checks for unused method arguments.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#underscore-unused-vars'
-  Enabled: true
-
-Lint/UnreachableCode:
-  Description: 'Unreachable code.'
-  Enabled: true
-
-Lint/UselessAccessModifier:
-  Description: 'Checks for useless access modifiers.'
-  Enabled: true
-
-Lint/UselessAssignment:
-  Description: 'Checks for useless assignment to a local variable.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#underscore-unused-vars'
-  Enabled: true
-
-Lint/BinaryOperatorWithIdenticalOperands:
-  Description: 'Checks for comparison of something with itself.'
-  Enabled: true
-
-Lint/UselessElseWithoutRescue:
-  Description: 'Checks for useless `else` in `begin..end` without `rescue`.'
-  Enabled: true
-
-Lint/UselessSetterCall:
-  Description: 'Checks for useless setter call to a local variable.'
-  Enabled: true
-
-Lint/Void:
-  Description: 'Possible use of operator/literal/variable in void context.'
-  Enabled: true
-
-###################### Metrics ####################################
-
-Metrics/BlockNesting:
-  Description: 'Avoid excessive block nesting'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#three-is-the-number-thou-shalt-count'
-  Enabled: true
-  Max: 4
-
-Metrics/ClassLength:
-  Description: 'Avoid classes longer than 260 lines of code.'
-  Enabled: true
-  Max: 260
-  Exclude:
-    - lib/pact_broker/test/*.rb
-
-Metrics/CyclomaticComplexity:
-  Description: >-
-                 A complexity metric that is strongly correlated to the number
-                 of test cases needed to validate a method.
-  Enabled: true
-  Exclude:
-    - ./lib/pact_broker/ui/app.rb
-
-Metrics/MethodLength:
-  Description: 'Avoid methods longer than 30 lines of code.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#short-methods'
-  Enabled: true
-  Max: 30
-  Exclude:
-    - ./lib/pact_broker/ui/app.rb
-
-Metrics/ModuleLength:
-  Description: 'Avoid modules longer than 250 lines of code.'
-  Enabled: true
-  Max: 250
-  Exclude:
-    - spec/**/*.rb
-    - lib/pact_broker/api/pact_broker_urls.rb
-
-Metrics/ParameterLists:
-  Description: 'Avoid parameter lists longer than three or four parameters.'
-  StyleGuide: 'https://github.com/bbatsov/ruby-style-guide#too-many-params'
-  Enabled: true
-  Exclude:
-    - lib/pact_broker/test/*.rb
-
-##################### Performance #############################
-
-Performance/Count:
-  Description: >-
-                  Use `count` instead of `select...size`, `reject...size`,
-                  `select...count`, `reject...count`, `select...length`,
-                  and `reject...length`.
-  Enabled: true
-
-Performance/Detect:
-  Description: >-
-                  Use `detect` instead of `select.first`, `find_all.first`,
-                  `select.last`, and `find_all.last`.
-  Reference: 'https://github.com/JuanitoFatas/fast-ruby#enumerabledetect-vs-enumerableselectfirst-code'
-  Enabled: true
-
-Performance/FlatMap:
-  Description: >-
-                  Use `Enumerable#flat_map`
-                  instead of `Enumerable#map...Array#flatten(1)`
-                  or `Enumberable#collect..Array#flatten(1)`
-  Reference: 'https://github.com/JuanitoFatas/fast-ruby#enumerablemaparrayflatten-vs-enumerableflat_map-code'
-  Enabled: true
-  EnabledForFlattenWithoutParams: false
-  # If enabled, this cop will warn about usages of
-  # `flatten` being called without any parameters.
-  # This can be dangerous since `flat_map` will only flatten 1 level, and
-  # `flatten` without any parameters can flatten multiple levels.
-
-Performance/ReverseEach:
-  Description: 'Use `reverse_each` instead of `reverse.each`.'
-  Reference: 'https://github.com/JuanitoFatas/fast-ruby#enumerablereverseeach-vs-enumerablereverse_each-code'
-  Enabled: true
-
-Style/Sample:
-  Description: >-
-                  Use `sample` instead of `shuffle.first`,
-                  `shuffle.last`, and `shuffle[Fixnum]`.
-  Reference: 'https://github.com/JuanitoFatas/fast-ruby#arrayshufflefirst-vs-arraysample-code'
-  Enabled: true
-
-Style/StringLiterals:
-  Description: Checks if uses of quotes match the configured preference.
-  Enabled: true
-  EnforcedStyle: double_quotes
-
-Performance/Size:
-  Description: >-
-                  Use `size` instead of `count` for counting
-                  the number of elements in `Array` and `Hash`.
-  Reference: 'https://github.com/JuanitoFatas/fast-ruby#arraycount-vs-arraysize-code'
-  Enabled: true
-
-Performance/StringReplacement:
-  Description: >-
-                  Use `tr` instead of `gsub` when you are replacing the same
-                  number of characters. Use `delete` instead of `gsub` when
-                  you are deleting characters.
-  Reference: 'https://github.com/JuanitoFatas/fast-ruby#stringgsub-vs-stringtr-code'
-  Enabled: true
-
-Layout/SpaceBeforeFirstArg:
-  Description: >-
-                 Checks that exactly one space is used between a method name
-                 and the first argument for method calls without parentheses.
-  Enabled: true

data/.ruby-version

@@ -1 +0,0 @@
-2.7.3

data/CODE_OF_CONDUCT.md

@@ -1,76 +0,0 @@
-# Contributor Covenant 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, sex characteristics, 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.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at pact-support@googlegroups.com. 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.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
-
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq

data/CONTRIBUTING.md

@@ -1,29 +0,0 @@
-# Raising issues
-
-Before raising an issue, make sure you have checked the [wiki] to see if an answer is provided there.
-There may also be an answer to your question on [stackoverflow].
-
-Please provide the following information with your issue to enable us to respond as quickly as possible.
-
-* The relevant versions of the gems or packages you are using.
-* The steps to recreate your issue.
-* An executable code example where possible.
-* Details of the environment the Pact Broker is deployed in (eg. docker, AWS, local machine)
-
-# Pull requests
-
-* Write tests for any changes
-* Follow existing code style and conventions
-* Separate unrelated changes into multiple pull requests
-* [Squash your commits][squash] into one commit before submitting your PR.
-* Use [semantic commit messages][semantic-commit-messages] so that your changes will show up correctly in the generated change log.
-
-* For bigger changes, make sure you start a discussion first by creating an issue and explaining the intended change
-
-See [DEVELOPER_SETUP.md](./DEVELOPER_SETUP.md) and [DEVELOPER_DOCUMENTATION.md](./DEVELOPER_DOCUMENTATION.md) for more information.
-
-[wiki]: https://github.com/pact-foundation/pact_broker/wiki
-[stackoverflow]: https://stackoverflow.com/questions/tagged/pact-broker
-[pact-ruby-e2e-example]: https://github.com/pact-foundation/pact-ruby-e2e-example
-[semantic-commit-messages]: http://karma-runner.github.io/2.0/dev/git-commit-msg.html
-[squash]: https://github.com/todotxt/todo.txt-android/wiki/Squash-All-Commits-Related-to-a-Single-Issue-into-a-Single-Commit

data/DEVELOPER_DOCUMENTATION.md

@@ -1,161 +0,0 @@
-# Developer Documentation
-
-## File structure
-
-* Application code - [lib](lib)
-  * The aggregated application (API, UI, middleware, HAL Browser, diagnostic endpoints etc) - [lib/pact_broker/app.rb](lib/pact_broker/app.rb)
-  * API - [lib/pact_broker/api](lib/pact_broker/api)
-    * Routes - [lib/pact_broker/api.rb](lib/pact_broker/api.rb)
-    * HTTP Resources - [lib/pact_broker/api/resources](lib/pact_broker/api/resources) These handle the HTTP requests.
-    * Decorators - [lib/pact_broker/api/decorators](lib/pact_broker/api/decorators) These parse the request bodies and render the response bodies.
-    * Contracts - [lib/pact_broker/api/contracts](lib/pact_broker/api/contracts) These validate incoming API requests.
-  * UI - [lib/pact_broker/ui](lib/pact_broker/ui)
-    * Routes - [lib/pact_broker/ui/app.rb](lib/pact_broker/ui/app.rb)
-    * Controllers - [lib/pact_broker/ui/controllers](lib/pact_broker/ui/controllers) These handle the HTTP requests.
-    * Views - [lib/pact_broker/ui/views](lib/pact_broker/ui/views) These render the view using HAML
-    * View models - [lib/pact_broker/ui/view_models](lib/pact_broker/ui/view_models) These expose the domain model data in a way that is suited to rendering in a view.
-  * Domain - Domain classes were intially created in [lib/pact_broker/domain](lib/pact_broker/domain) but are now put in their own modules. The ones left here just haven't been migrated yet. The module name is the plural of the domain class name. eg `lib/pact_broker/widgets/widget.rb`.
-  * Services and Repositories - in the module with the name of their domain concept. eg `lib/pact_broker/widgets/service.rb` and `lib/pact_broker/widgets/repository.rb`
-  * Standalone "function as class" classes go into the module they relate to. This pattern is used when there is some significant stateless logic that we want to
-* Database migrations - [db/migrations](db/migrations)
-
-* Tests - `spec`
-  * Isolated tests (mostly) - `spec/lib`
-  * Contract tests - `spec/service_consumers`
-  * High level API functional tests - `spec/features`
-  * Migration tests - `spec/migrations`
-
-## Domain and database design
-
-### Domain
-
-Domain classes are found in `lib/pact_broker/domain`. Many of these classes are Sequel models, as the difference between the Sequel model and the functionality required for the domain logic is similar enough to share the class. Some classes separate the domain and database logic, as the concerns are too different. Where there is a separate database model, this will be kept in a module with the pluralized name of the model eg. `PactBroker::Webhooks`. Unfortunately, this sometimes makes it difficult to tell in the calling code whether you have a domain or a database model. I haven't worked out a clean way to handle this yet.
-
-### Domain terminology
-
-* `pacticipant` - an application that participates in a pact. A very bad pun which I deeply regret.
-* `pact` - this term is confusing and overloaded. It generally means a `pact publication` in the code.
-* `pact publication` - the resource that gets created when a PUT request is sent to the Pact Broker to `/pacts/provider/PROVIDER/consumer/CONSUMER/version/VERSION`.
-* `pact version` - the JSON contents of the pact publication. One pact version may belong to many pact publications. That is, if a pact publication with exactly the same contents is published twice, then a new
-pact publication resource will be created with an incremented revision number, but it will reuse the existing pact version.
-* `pacticipant version` - a resource that represents a version of the application
-* `integration` - the relationship between a consumer and a provider
-* `pseudo branch` - A time ordered list of pacts that are related to a particular tag. The most recent pact for each pseudo branch is a "head" pact.
-* `matrix` - the table that shows the cartesian join of pact versions/verifications, and hence shows which consumer versions and provider versions have been tested together.
-
-### Tables
-* `pact_versions` - the JSON content of each UNIQUE pact document is stored in this table. The same content is likely to be published over and over again by the CI builds, so deduplicating the content saves us a lot of disk space. Once created, a row is never modified. Uniqueness is just done on string equality - no special pact logic. This means that pacts with randomly generated values or orders (most of pact-jvm pacts!) will get a new version record every time they publish.
-
-* `pact_publications` - this table holds references to the:
-
-    * `provider` (in the pacticipants table)
-    * `consumer version` (in the versions table),
-    * `pact content` (in the pact_version_contents table)
-    * and a `revision number`
-
- A row exists for every `PUT` or `PATCH` request made to create or update a given pact resource. Once created, a row is never modified. When a pact resource (defined by the `provider`, `consumer` and `consumer version number`) is modified via HTTP, a new `pact_revision` row is created with an incremented `revision_number`. The `revision_number` begins at 1 for each new `consumer_version`.
-
-* `versions` - this table consists of:
-
-    * a reference to the `pacticipant` that owns the version (the `consumer`)
-    * the version `number` (eg. 1.0.2)
-    * the version `order` - an integer calculated by the code when the row is created that allows us to sort versions in the database without it needing to understand how to order semantic version strings. The versions are ordered within the context of their owning `pacticipant`.
-
- Currently only consumer versions are stored, as these are created when a pact resource is created. There is potential to create provider versions when we implement verifications.
-
-* `pacticipants` - this table consists of:
-
-    * a `name`
-
-* `tags` - this table consists of:
-
-    * a `name`
-    * a reference to the `pacticipant version`
-
- Note that a `consumer version` is tagged, rather than a `pact_version`. This means that when a given version is marked as the "prod" one, all the pacts for that version are considered the "prod" pacts, rather than having to tag them individually.
-
-### Views
-
-* `all_pact_publications` - A denormalised view the one-to-one attributes of a `pact_publication`, including:
-
-    * `provider name` and `provider id`
-    * `consumer name` and `consumer id`
-    * `consumer version number` and `consumer version order`
-    * `revision_number`
-
-* `latest_pact_publications_by_consumer_versions` - This view has the same columns as `all_pact_publications`, but it only contains the latest revision of the pact for each provider/consumer/version. It maps to what a user would consider the "pact" resource ie. `/pacts/provider/PROVIDER/consumer/CONSUMER/version/VERSION`. Previous revisions are not currently exposed via the API.
-
-* `latest_pact_publications` - This view has the same columns as `all_pact_publications`, but it only contains the latest revision of the pact for the latest consumer version for each consumer/provider pair. It is what a user would consider the "latest pact", and maps to the resource at `/pacts/provider/PROVIDER/consumer/CONSUMER/latest`
-
-* `latest_tagged_pact_publications` - This view has the same columns as `all_pact_publications`, plus a `tag_name` column. It is used to return the pact for the latest tagged version of a consumer.
-
-* `latest_verifications_for_pact_versions` - The most recent verification for each pact version.
-
-* `matrix` - The matrix of every pact publication and verification. Includes every pact revision (eg. publishing to the same consumer version twice, or using PATCH) and every verification (including 'overwritten' ones. eg. when the same provider build runs twice.)
-
-### Dependencies
-
-```
-= head_matrix view
-  -> latest_pact_publications view
-    -> latest_pact_publications_by_consumer_versions view
-      -> latest_pact_publication_ids_by_consumer_versions
-      -> all_pact_publications
-        -> versions, pacticipants, pact_publications, pact_versions
-  -> latest_verifications_for_pact_versions
-    -> latest_verification_ids_for_pact_versions
-    -> versions
-  -> latest_tagged_pact_consumer_version_orders
-  -> latest_pact_publications_by_consumer_versions
-
-= head_pact_publications
-  -> latest_pact_publications
-    -> latest_pact_publication_ids_for_consumer_versions
-  -> latest_tagged_pact_publications
-    -> latest_pact_publications_by_consumer_versions (optimised for pp_ids)
-    -> latest_tagged_pact_consumer_version_orders (optimised for pp_ids)
-
-```
-
-### Database modeling approach
-
-In the beginning, I made a lot of Sequel models based on views that pulled in the different tables of data together (eg denormalising consumer, provider, pact publication and pact version in to `all_pact_publications`). This made the Ruby code quite simple, but it was not very performant. As time has progressed, I have moved more and more of the "data joining" code into the Ruby to optimise the queries. That's why there are a lot of "aggregated data" views that are not being used by the code any more.
-
-### Useful to know stuff
-
-* The supported database types are Postgres (recommended), MySQL (sigh) and Sqlite (just for testing, not recommended for production). Check the travis.yml file for the supported database versions.
-* Any migration that uses the "order" column has to be defined using the Sequel DSL rather than pure SQL, because the word "order" is a key word, and it has to be escaped correctly and differently on each database (Postgres, MySQL, Sqlite).
-
-## Adding a resource
-
-* In `spec/features` add a new high level spec that executes the endpoint you're going to write. Don't worry if you're not sure exactly what it's going to look like yet - you can come back and change it as you go. Have a look at the other specs in the directory for the type of assertions that should be made. Basic rule of thumb is to check the http status code, and do a light touch of assertions on the body.
-* Create a new directory for the classes that relate to your new resource. eg For a "Foo" resource, create `lib/pact_broker/foos`
-* Create a new migration in `db/migrations` that creates the underlying database table.
-* Create a new database model for the resource that extends from Sequel::Model. eg `lib/pact_broker/foos/foo.rb`
-* Create a decorator in `spec/lib/pact_broker/api/decorators/` that will map to and from the representation that will be used in the HTTP request and response.
-  * Write a spec for the decorator.
-* You may need to create a contract to validate the request. This is kind of broken while I upgrade to the latest dry-validation library. See Beth for more details.
-* Add the HTTP resource in `lib/pact_broker/api/resources/`. It should extend from `BaseResource`.
-  * Write a spec for the resource, stubbing out the behaviour you expect from your service.
-* Add the route to `lib/pact_broker/api.rb`
-* Create a service that has the methods that you need for the resource. eg. `lib/pact_broker/foos/service.rb`
-  * Add the new service to `lib/pact_broker/services.rb`
-  * Write a spec for the service, stubbing out the behaviour you expect from your repository.
-* Create a repository eg. `lib/pact_broker/foos/repository.rb`.
-  * Add the new repository to `lib/pact_broker/repositories.rb`.
-  * Write a spec for the repository.
-* Go back and make the original feature spec pass.
-* Profit.
-
-## Writing Data migrations
-
-The same database may be used by multiple application instances to support highly available set ups and no downtime deployments. This can lead to the situation where the database migrations have been applied, but new data is written to the database by old application code, which may lead to some columns not being populated. The mitigation to this problem is to run the *data* migrations only each time an application instance starts up. This ensures that that any data inserted into the database by a previous version of the application are migrated. This is done automatically in the `PactBroker::App` class.
-
-If you write a schema migration that then requires a data migration to populate or update any columns:
-
-* Create a data migrations class in `lib/pact_broker/db/data_migrations`, copying the existing pattern.
-* Add a call to the new class at the end of `lib/pact_broker/db/migrate_data.rb`
-* Make sure you check for the existance of the required columns, because you don't know which version of the database might be running with this code.
-* Add a null check (eg. `db[:my_table].where(my_column: nil).update(...)`) where appropriate to make sure that the data migration doesn't run more than once.
-* Don't use any Sequel Models, as this will run before the model classes are loaded, and migrations should never depend on Models because models change as the schema migrations are applied.
-* Create a migration file in `db/migrations` that calls the data migration (eg. like `db/migrations/20190603_migrate_webhook_headers.rb`)