Merge pull request #283 from building-envelope-data/release/v1.0.0

Release version v1.0.0

Author: simon-wacker

.dockerignore

@@ -3,4 +3,7 @@
 *.md
 Makefile
 Dockerfile
+apis/*.schema.json
+npm-debug.log
+node_modules
 tags

.github/workflows/draft-new-release.yml

@@ -0,0 +1,61 @@
+# Almost literally taken from
+# https://github.com/thomaseizinger/github-action-gitflow-release-workflow/blob/dev/.github/workflows/draft-new-release.yml
+
+name: "Draft new release"
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: 'The version you want to release following semantic versioning (for example, `v1.4.3`, see https://semver.org).'
+        required: true
+
+jobs:
+  draft-new-release:
+    name: "Draft new release"
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Create release branch
+        run: git checkout -b release/${{ github.event.inputs.version }}
+
+      - name: Update changelog
+        uses: thomaseizinger/keep-a-changelog-new-release@1.2.1
+        with:
+          version: ${{ github.event.inputs.version }}
+
+      # In order to make a commit, we need to initialize a user.
+      # You may choose to write something less generic here if you want, it doesn't matter functionality wise.
+      - name: Initialize mandatory git config
+        run: |
+          git config user.name "GitHub Actions"
+          git config user.email noreply@github.com
+
+      - name: Commit changelog and manifest files
+        id: make-commit
+        run: |
+          git add CHANGELOG.md
+          git commit --message "Prepare release ${{ github.event.inputs.version }}"
+          echo "::set-output name=commit::$(git rev-parse HEAD)"
+      - name: Push new branch
+        run: git push origin release/${{ github.event.inputs.version }}
+
+      - name: Create pull request
+        uses: thomaseizinger/create-pull-request@1.0.0
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          head: release/${{ github.event.inputs.version }}
+          base: main
+          title: Release version ${{ github.event.inputs.version }}
+          reviewers: ${{ github.actor }} # By default, we request a review from the person who triggered the workflow.
+          # Write a nice message to the user.
+          # We are claiming things here based on the `publish-new-release.yml` workflow.
+          # You should obviously adopt it to say the truth depending on your release workflow :)
+          body: |
+            Hi @${{ github.actor }}!
+
+            This pull request was created in response to a manual trigger of the release workflow here: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}.
+            I've updated the changelog and bumped the versions in the manifest files in this commit: ${{ steps.make-commit.outputs.commit }}.
+            Merging this pull request will create a GitHub release and upload any assets that are created as part of the release build.

.github/workflows/publish-new-release.yml

@@ -0,0 +1,54 @@
+# Almost literally taken from
+# https://github.com/thomaseizinger/github-action-gitflow-release-workflow/blob/dev/.github/workflows/publish-new-release.yml
+
+name: "Publish new release"
+
+on:
+  pull_request:
+    branches:
+      - main
+    types:
+      - closed
+
+jobs:
+  release:
+    name: Publish new release
+    runs-on: ubuntu-latest
+    if: github.event.pull_request.merged == true # only merged pull requests must trigger this job
+    steps:
+      - name: Extract version from branch name (for release branches)
+        if: startsWith(github.event.pull_request.head.ref, 'release/')
+        run: |
+          BRANCH_NAME="${{ github.event.pull_request.head.ref }}"
+          VERSION=${BRANCH_NAME#release/}
+          echo "RELEASE_VERSION=$VERSION" >> $GITHUB_ENV
+      - name: Extract version from branch name (for hotfix branches)
+        if: startsWith(github.event.pull_request.head.ref, 'hotfix/')
+        run: |
+          BRANCH_NAME="${{ github.event.pull_request.head.ref }}"
+          VERSION=${BRANCH_NAME#hotfix/}
+          echo "RELEASE_VERSION=$VERSION" >> $GITHUB_ENV
+      - name: Create Release
+        uses: thomaseizinger/create-release@1.0.0
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          target_commitish: ${{ github.event.pull_request.merge_commit_sha }}
+          tag_name: ${{ env.RELEASE_VERSION }}
+          name: ${{ env.RELEASE_VERSION }}
+          draft: false
+          prerelease: false
+
+      - name: Merge main into develop branch
+        uses: thomaseizinger/create-pull-request@1.0.0
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          head: main
+          base: develop
+          title: Merge main into develop branch
+          body: |
+            This pull request merges the main branch back into develop.
+            This happens to ensure that the updates that happend on the release branch, in particular, CHANGELOG and manifest updates, are also present on the develop branch.
+      # if needed, you can checkout the latest main here, build artifacts and publish / deploy them somewhere
+      # the create-release action has an output `upload_url` output that you can use to upload assets

.gitignore

@@ -1 +1,4 @@
+/apis/*.schema.json
+/npm-debug.log
+/node_modules
 /tags

.graphql-schema-linterrc

@@ -1,21 +1,10 @@
 {
   "rules": [
-    //"arguments-have-descriptions",
-    //"defined-types-are-used",
     "deprecations-have-a-reason",
     "descriptions-are-capitalized",
     "enum-values-all-caps",
-    //"enum-values-have-descriptions",
-    //"enum-values-sorted-alphabetically",
     "fields-are-camel-cased",
-    //"fields-have-descriptions",
-    //"input-object-fields-sorted-alphabetically",
     "input-object-values-are-camel-cased",
-    //"input-object-values-have-descriptions",
-    "relay-connection-types-spec",
-    //"relay-connection-arguments-spec",
-    //"type-fields-sorted-alphabetically",
     "types-are-capitalized",
-    //"types-have-descriptions"
   ]
 }

.graphqlrc

@@ -0,0 +1,7 @@
+projects:
+  database:
+    schema: './apis/database.graphql'
+    documents: './queries/database/**/*.graphql'
+  metabase:
+    schema: './apis/metabase.graphql'
+    documents: './queries/metabase/**/*.graphql'

CHANGELOG.md

@@ -1,4 +1,5 @@
 # Changelog
+
 All notable changes to this project will be documented in this file.
 
 The format is based on
@@ -7,7 +8,9 @@ and this project adheres to
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ## [Unreleased]
+
 ### Added
+
 -
 -
 -
@@ -30,6 +33,7 @@ and this project adheres to
 -
 
 ### Changed
+
 -
 -
 -
@@ -52,6 +56,7 @@ and this project adheres to
 -
 
 ### Deprecated
+
 -
 -
 -
@@ -74,6 +79,7 @@ and this project adheres to
 -
 
 ### Removed
+
 -
 -
 -
@@ -96,6 +102,7 @@ and this project adheres to
 -
 
 ### Fixed
+
 -
 -
 -
@@ -118,6 +125,7 @@ and this project adheres to
 -
 
 ### Security
+
 -
 -
 -
@@ -139,14 +147,75 @@ and this project adheres to
 -
 -
 
-## [0.1.0] - 2020-08-31
+## [v1.0.0] - 2022-03-02
+
+### Added
+
+-   Document previously undocumented database GraphQL schema [#101](https://github.com/building-envelope-data/api/pull/101)
+-   Add more tooling for GraphQL schema, queries, and mutations [#104](https://github.com/building-envelope-data/api/pull/104)
+-   Add query examples for `data`, `allData`, and `hasData` [#105](https://github.com/building-envelope-data/api/pull/105)
+-   Add section to publication to be able to refer to just one part of a publication [#155](https://github.com/building-envelope-data/api/pull/155)
+-   Add two examples of methods for daylighting and glare simulations [#179](https://github.com/building-envelope-data/api/pull/179)
+-   Add version to JSON Schema `$id`s [#188](https://github.com/building-envelope-data/api/pull/188)
+-   Add examples photovoltaicWithOptical [#207](https://github.com/building-envelope-data/api/pull/207), semitransparentBuildingIntegratedPhotovoltaicThermal [#209](https://github.com/building-envelope-data/api/pull/209), from ES-SDA [#213](https://github.com/building-envelope-data/api/pull/213) and dataFormatPdf [#226](https://github.com/building-envelope-data/api/pull/226)
+-   Add the key `roughness` [#205](https://github.com/building-envelope-data/api/pull/205)
+-   Add the position of coatings to components [#223](https://github.com/building-envelope-data/api/pull/223)
+-   Add `currentVoltage` characteristics for modules [#224](https://github.com/building-envelope-data/api/pull/224)
+-   Add release actions [#281](https://github.com/building-envelope-data/api/pull/281)
+
+### Changed
+
+-   Improve propositions used in GraphQL queries to search for data [#102](https://github.com/building-envelope-data/api/pull/102)
+-   Further align database GraphQL schema and JSON schema [#103](https://github.com/building-envelope-data/api/pull/103)
+-   Flatten data HTTP resource trees to make them queryable with one query without having to know the trees depth [#108](https://github.com/building-envelope-data/api/pull/108)
+-   Only use `additionalItems` for tuple validation and **not** for list validation, use `uniqueItems` for lists of enumerated items, use `const` for one-valued enums, and don't have special this-property-has-no-value values for optional properties [#110](https://github.com/building-envelope-data/api/pull/110)
+-   Improve titles and descriptions of identifiers, name `uniqueId` of decentral identifiers `value`, and make identifiers be issued by databases instead of institutions [#107](https://github.com/building-envelope-data/api/pull/107)
+-   Clean-up the stakeholder JSON schema, in particular, how stakeholders are referenced in specific roles [#111](https://github.com/building-envelope-data/api/pull/111)
+-   Associate contact information and GnuPG keys with a person's and institution's affiliations [#112](https://github.com/building-envelope-data/api/pull/112)
+-   Check and correct usages of `oneOf`, `anyOf`, and `allOf` [#113](https://github.com/building-envelope-data/api/pull/113)
+-   Use specific instead of general and (almost) meaningless number definitions [#114](https://github.com/building-envelope-data/api/pull/114)
+-   Improve titles and descriptions in the JSON Schema for optical data [#115](https://github.com/building-envelope-data/api/pull/115)
+-   Improve documentation of approvals in the database GraphQL schema [#117](https://github.com/building-envelope-data/api/pull/117)
+-   Clean-up Dockerfile, in particular, remove notes regarding Python [#121](https://github.com/building-envelope-data/api/pull/121)
+-   Correct minor errors in database GraphQL API [#173](https://github.com/building-envelope-data/api/pull/173)
+-   Name `dataId` `uuid`, remove `validity` from `*Data` and `DataApproval`, use parent identifier instead of child identifiers to describe tree structure, do not require response approvals to be created on the fly [#180](https://github.com/building-envelope-data/api/pull/180)
+-   Update GraphqL schema of metabase to match the current deployed version [#280](https://github.com/building-envelope-data/api/pull/280)
+-   Rename organization to `building-envelope-data` and API repository to `api` [#277](https://github.com/building-envelope-data/api/pull/277)
+-   Use acronyms to identify standardizers [#154](https://github.com/building-envelope-data/api/pull/154)
+-   Use JSON Schema Draft 2019-09 and upgrade tooling [#181](https://github.com/building-envelope-data/api/pull/181)
+-   Restructure `numbersWithUncertainty` to make the data less verbose[#195](https://github.com/building-envelope-data/api/pull/195),[#216](https://github.com/building-envelope-data/api/pull/216)
+-   Improve the structure of geometry.json [#205](https://github.com/building-envelope-data/api/pull/205)
+-   Improve the structure of calorimetricData.json [#209](https://github.com/building-envelope-data/api/pull/209)]
+-   Correct the requirements of `emergenceDirection`[#213](https://github.com/building-envelope-data/api/pull/213)
+-   Offer detailed definition of calorimetric fluxes [#222](https://github.com/building-envelope-data/api/pull/222)
+-   Add categories to `material`, `layer` and `unit` from EN 12216 [#223](https://github.com/building-envelope-data/api/pull/223) and from EN 13024-1, EN 14179, EN 1863, DIN 18008-5 [#224](https://github.com/building-envelope-data/api/pull/224)
+-   Add more mirrored values to `apis` [#238](https://github.com/building-envelope-data/api/pull/238)
+-   Add spectrum `ultraviolet` for integral values and improve the optical examples [#247](https://github.com/building-envelope-data/api/pull/247)
+-   Change propositions for lists and make parameter `where` optional [#260](https://github.com/building-envelope-data/api/pull/260)
+
+### Removed
+
+-   Remove intermediate representation of optical data [#152](https://github.com/building-envelope-data/api/pull/152)
+-   Remove custom directions from optical data [#153](https://github.com/building-envelope-data/api/pull/153)
+-   Remove `validity` everywhere except of `method` which can depend for example on a standard [#219](https://github.com/building-envelope-data/api/pull/219)
+
+### Fixed
+
+-   Fix the three phase method test by using enumerated standardizers instead of identifiers [#192](https://github.com/building-envelope-data/api/pull/192)
+
+## [v0.1.0] - 2020-08-31
+
 First major-version-zero release
 [0.1.0](https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase).
 
 Note that according to
 [Semantic Versioning Specification, Item 4](https://semver.org/#spec-item-4),
+
 > Major version zero (0.y.z) is for initial development. Anything MAY change at
 > any time. The public API SHOULD NOT be considered stable.
 
-[Unreleased]: https://github.com/ise621/building-envelope-data/compare/v0.1.0...HEAD
-[0.1.0]: https://github.com/ise621/building-envelope-data/releases/tag/v0.1.0
+[Unreleased]: https://github.com/building-envelope-data/api/compare/v1.0.0...HEAD
+
+[v1.0.0]: https://github.com/building-envelope-data/api/compare/v0.1.0...v1.0.0
+
+[v0.1.0]: https://github.com/building-envelope-data/api/releases/tag/v0.1.0

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# 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 christoph.maurer@ise.fraunhofer.de. 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