Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update main with next #2868

Merged
merged 8 commits into from
Nov 27, 2023
Merged

Update main with next #2868

merged 8 commits into from
Nov 27, 2023

Conversation

sachindshinde
Copy link
Contributor

No description provided.

unflxw and others added 8 commits August 18, 2023 16:58
Add more information to OpenTelemetry spans.

Rename `operationName` to `graphql.operation.name` and add a
`graphql.operation.type` attribute, in conformance with the OpenTelemetry
Semantic Conventions for GraphQL. The `operationName` attribute is now
deprecated, but it is still emitted alongside `graphql.operation.name`.

Add a `graphql.document` span attribute to the `gateway.request` span,
containing the entire GraphQL source sent in the request. This feature
is disabled by default.

When one or more GraphQL or internal errors occur, report them in the
OpenTelemetry span in which they took place, as an exception event. This
feature is disabled by default.

To enable the `graphql.document` span attribute and the exception event
reporting, add the following entries to your `ApolloGateway` instance
configuration:

```ts
const gateway = new ApolloGateway({
  // ...
  telemetry: {
    // Set to `true` to include the `graphql.document` attribute
    includeDocument: true,
    // Set to `true` to report all exception events, or set to a number
    // to report at most that number of exception events per span
    reportExceptions: true,
    // or: reportExceptions: 1
  },
});
```
Introduce the new `@policy` scope for composition

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.
  
Users may now compose `@policy` applications from their subgraphs into a
supergraph.

  The directive is defined as follows:

  ```graphql
  scalar federation__Policy

  directive @Policy(policies: [[federation__Policy!]!]!) on
    | FIELD_DEFINITION
    | OBJECT
    | INTERFACE
    | SCALAR
    | ENUM
  ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:
  ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
  ```

For additional context, this PR effectively follows the pattern
implemented by #2644

---------

Co-authored-by: Dariusz Kuc <9501705+dariuszkuc@users.noreply.github.com>
Co-authored-by: Geoffroy Couprie <apollo@geoffroycouprie.com>
Co-authored-by: Trevor Scheer <trevor.scheer@gmail.com>
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to next, this PR will
be updated.


# Releases
## @apollo/composition@2.6.0

### Minor Changes

- Update `license` field in `package.json` to use `Elastic-2.0` SPDX
identifier
([#2741](#2741))


- Introduce the new `@policy` scope for composition
([#2818](#2818))

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

Users may now compose `@policy` applications from their subgraphs into a
supergraph.

      The directive is defined as follows:

    ```graphql
    scalar federation__Policy

    directive @Policy(policies: [[federation__Policy!]!]!) on
      | FIELD_DEFINITION
      | OBJECT
      | INTERFACE
      | SCALAR
      | ENUM
    ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:

    ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
    ```

### Patch Changes

- Updated dependencies
\[[`b18841be`](b18841b),
[`e325b499`](e325b49)]:
    -   @apollo/query-graphs@2.6.0
    -   @apollo/federation-internals@2.6.0

## @apollo/gateway@2.6.0

### Minor Changes

- Add more information to OpenTelemetry spans.
([#2700](#2700))

    Rename `operationName` to `graphql.operation.name` and add a
`graphql.operation.type` attribute, in conformance with the
OpenTelemetry
Semantic Conventions for GraphQL. The `operationName` attribute is now
deprecated, but it is still emitted alongside `graphql.operation.name`.

Add a `graphql.document` span attribute to the `gateway.request` span,
containing the entire GraphQL source sent in the request. This feature
    is disable by default.

When one or more GraphQL or internal errors occur, report them in the
OpenTelemetry span in which they took place, as an exception event. This
    feature is disabled by default.

To enable the `graphql.document` span attribute and the exception event
reporting, add the following entries to your `ApolloGateway` instance
    configuration:

    ```ts
    const gateway = new ApolloGateway({
      // ...
      telemetry: {
        // Set to `true` to include the `graphql.document` attribute
        includeDocument: true,
// Set to `true` to report all exception events, or set to a number
        // to report at most that number of exception events per span
        reportExceptions: true,
        // or: reportExceptions: 1
      },
    });
    ```

- Update `license` field in `package.json` to use `Elastic-2.0` SPDX
identifier
([#2741](#2741))


- Introduce the new `@policy` scope for composition
([#2818](#2818))

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

Users may now compose `@policy` applications from their subgraphs into a
supergraph.

      The directive is defined as follows:

    ```graphql
    scalar federation__Policy

    directive @Policy(policies: [[federation__Policy!]!]!) on
      | FIELD_DEFINITION
      | OBJECT
      | INTERFACE
      | SCALAR
      | ENUM
    ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:

    ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
    ```

- Add graphql.operation.name attribute on gateway.plan span
([#2807](#2807))

### Patch Changes

- Updated dependencies
\[[`b18841be`](b18841b),
[`e325b499`](e325b49)]:
    -   @apollo/query-planner@2.6.0
    -   @apollo/composition@2.6.0
    -   @apollo/federation-internals@2.6.0

## @apollo/federation-internals@2.6.0

### Minor Changes

- Update `license` field in `package.json` to use `Elastic-2.0` SPDX
identifier
([#2741](#2741))


- Introduce the new `@policy` scope for composition
([#2818](#2818))

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

Users may now compose `@policy` applications from their subgraphs into a
supergraph.

      The directive is defined as follows:

    ```graphql
    scalar federation__Policy

    directive @Policy(policies: [[federation__Policy!]!]!) on
      | FIELD_DEFINITION
      | OBJECT
      | INTERFACE
      | SCALAR
      | ENUM
    ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:

    ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
    ```

## @apollo/query-graphs@2.6.0

### Minor Changes

- Update `license` field in `package.json` to use `Elastic-2.0` SPDX
identifier
([#2741](#2741))


- Introduce the new `@policy` scope for composition
([#2818](#2818))

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

Users may now compose `@policy` applications from their subgraphs into a
supergraph.

      The directive is defined as follows:

    ```graphql
    scalar federation__Policy

    directive @Policy(policies: [[federation__Policy!]!]!) on
      | FIELD_DEFINITION
      | OBJECT
      | INTERFACE
      | SCALAR
      | ENUM
    ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:

    ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
    ```

### Patch Changes

- Updated dependencies
\[[`b18841be`](b18841b),
[`e325b499`](e325b49)]:
    -   @apollo/federation-internals@2.6.0

## @apollo/query-planner@2.6.0

### Minor Changes

- Update `license` field in `package.json` to use `Elastic-2.0` SPDX
identifier
([#2741](#2741))


- Introduce the new `@policy` scope for composition
([#2818](#2818))

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

Users may now compose `@policy` applications from their subgraphs into a
supergraph.

      The directive is defined as follows:

    ```graphql
    scalar federation__Policy

    directive @Policy(policies: [[federation__Policy!]!]!) on
      | FIELD_DEFINITION
      | OBJECT
      | INTERFACE
      | SCALAR
      | ENUM
    ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:

    ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
    ```

### Patch Changes

- Updated dependencies
\[[`b18841be`](b18841b),
[`e325b499`](e325b49)]:
    -   @apollo/query-graphs@2.6.0
    -   @apollo/federation-internals@2.6.0

## @apollo/subgraph@2.6.0

### Patch Changes

- Updated dependencies
\[[`b18841be`](b18841b),
[`e325b499`](e325b49)]:
    -   @apollo/federation-internals@2.6.0

## apollo-federation-integration-testsuite@2.6.0

### Minor Changes

- Update `license` field in `package.json` to use `Elastic-2.0` SPDX
identifier
([#2741](#2741))


- Introduce the new `@policy` scope for composition
([#2818](#2818))

> Note that this directive will only be _fully_ supported by the Apollo
Router as a GraphOS Enterprise feature at runtime. Also note that
_composition_ of valid `@policy` directive applications will succeed,
but the resulting supergraph will not be _executable_ by the Gateway or
an Apollo Router which doesn't have the GraphOS Enterprise entitlement.

Users may now compose `@policy` applications from their subgraphs into a
supergraph.

      The directive is defined as follows:

    ```graphql
    scalar federation__Policy

    directive @Policy(policies: [[federation__Policy!]!]!) on
      | FIELD_DEFINITION
      | OBJECT
      | INTERFACE
      | SCALAR
      | ENUM
    ```

The `Policy` scalar is effectively a `String`, similar to the `FieldSet`
type.

In order to compose your `@policy` usages, you must update your
subgraph's federation spec version to v2.6 and add the `@policy` import
to your existing imports like so:

    ```graphql
@link(url: "https://specs.apollo.dev/federation/v2.6", import: [...,
"@Policy"])
    ```

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
@sachindshinde sachindshinde requested a review from a team as a code owner November 27, 2023 20:38
Copy link

changeset-bot bot commented Nov 27, 2023

⚠️ No Changeset found

Latest commit: b6bcfd8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

netlify bot commented Nov 27, 2023

Deploy Preview for apollo-federation-docs canceled.

Name Link
🔨 Latest commit b6bcfd8
🔍 Latest deploy log https://app.netlify.com/sites/apollo-federation-docs/deploys/6564fe31a249680008f26478

Copy link

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

@sachindshinde sachindshinde merged commit 6d700a7 into main Nov 27, 2023
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants