Easily use Storybook with ReasonML!
jbaxleyiii/apollo-server-cloudflare 30
An example application showing how to use ApolloServer with Cloudflare workers
jbaxleyiii/authors-and-posts-reason 21
Authors and Posts from Apollo Launchpad in ReasonML
jbaxleyiii/hapi-16-with-engine 4
Example app showing using Engine with Hapi 16
jbaxleyiii/apollo-cache-hermes 2
A cache implementation for Apollo Client, tuned for performance
jbaxleyiii/apollo-cache-persist 1
Simple persistence for all Apollo Cache implementations
delete branch apollographql/spaceport
delete branch : dependabot/npm_and_yarn/node-fetch-2.6.1
delete time in 20 days
push eventapollographql/spaceport
commit sha d30abb7f3007f253293ef7ceca355926f1df208a
Bump node-fetch from 2.6.0 to 2.6.1 Bumps [node-fetch](https://github.com/bitinn/node-fetch) from 2.6.0 to 2.6.1. - [Release notes](https://github.com/bitinn/node-fetch/releases) - [Changelog](https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md) - [Commits](https://github.com/bitinn/node-fetch/compare/v2.6.0...v2.6.1) Signed-off-by: dependabot[bot] <[email protected]>
commit sha 3ea449a259ad722a321806045b6ece91922ff60b
Merge pull request #3 from apollographql/dependabot/npm_and_yarn/node-fetch-2.6.1 Bump node-fetch from 2.6.0 to 2.6.1
push time in 20 days
PR merged apollographql/spaceport
Bumps node-fetch from 2.6.0 to 2.6.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/bitinn/node-fetch/releases">node-fetch's releases</a>.</em></p> <blockquote> <h2>v2.6.1</h2> <p><strong>This is an important security release. It is strongly recommended to update as soon as possible.</strong></p> <p>See <a href="https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md#v261">CHANGELOG</a> for details.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md">node-fetch's changelog</a>.</em></p> <blockquote> <h2>v2.6.1</h2> <p><strong>This is an important security release. It is strongly recommended to update as soon as possible.</strong></p> <ul> <li>Fix: honor the <code>size</code> option after following a redirect.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/node-fetch/node-fetch/commit/b5e2e41b2b50bf2997720d6125accaf0dd68c0ab"><code>b5e2e41</code></a> update version number</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/2358a6c2563d1730a0cdaccc197c611949f6a334"><code>2358a6c</code></a> Honor the <code>size</code> option after following a redirect and revert data uri support</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/8c197f8982a238b3c345c64b17bfa92e16b4f7c4"><code>8c197f8</code></a> docs: Fix typos and grammatical errors in README.md (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/686">#686</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/1e99050f944ac435fce26a9549eadcc2419a968a"><code>1e99050</code></a> fix: Change error message thrown with redirect mode set to error (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/653">#653</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/244e6f63d42025465796e3ca4ce813bf2c31fc5b"><code>244e6f6</code></a> docs: Show backers in README</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/6a5d192034a0f438551dffb6d2d8df2c00921d16"><code>6a5d192</code></a> fix: Properly parse meta tag when parameters are reversed (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/682">#682</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/47a24a03eb49a49d81b768892aee10074ed54a91"><code>47a24a0</code></a> chore: Add opencollective badge</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/7b136627c537cb24430b0310638c9177a85acee1"><code>7b13662</code></a> chore: Add funding link</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/5535c2ed478d418969ecfd60c16453462de2a53f"><code>5535c2e</code></a> fix: Check for global.fetch before binding it (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/674">#674</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/1d5778ad0d910dbd1584fb407a186f5a0bc1ea22"><code>1d5778a</code></a> docs: Add Discord badge</li> <li>Additional commits viewable in <a href="https://github.com/bitinn/node-fetch/compare/v2.6.0...v2.6.1">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~akepinski">akepinski</a>, a new releaser for node-fetch since your current version.</p> </details> <br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
<details> <summary>Dependabot commands and options</summary> <br />
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the Security Alerts page.
</details>
pr closed time in 20 days
Pull request review commentapollographql/rover
impl Rover { } } }++impl Report for Rover {+ fn serialize_command(&self) -> Result<String, SputnikError> {+ Ok(serde_json::to_string(&self)?)+ }++ fn is_enabled(&self) -> bool {+ option_env!("APOLLO_TELEMETRY_DISABLED").is_none()
We will need some installer disclosure (as well as docs) about this variable and our usage of telemetry
comment created time in 22 days
Pull request review commentapollographql/rover
+use ci_info::types::Vendor as CiVendor;+use reqwest::Url;+use semver::Version;+use serde::Serialize;+use sha2::{Digest, Sha256};+use uuid::Uuid;++use std::env::{consts::OS, current_dir};+use std::fmt::Debug;+use std::time::Duration;++use crate::{Report, SputnikError};++/// The Session represents a usage of the CLI analogous to a web session+/// It contains the "url" (command path + flags) but doesn't contain any+/// values entered by the user. It also contains some identity information+/// for the user+#[derive(Debug, Serialize)]+pub struct Session {+ /// the command usage where commands are paths and flags are query strings+ /// i.e. rover profile list --help would become rover/profile/list?help
I think this was my original comment and we didn't end up doing this so we should change this comment :)
comment created time in 22 days
Pull request review commentapollographql/rover
use anyhow::Result; use rover::*;+use sputnik::Session; use structopt::StructOpt; +use std::thread;+ fn main() -> Result<()> { logger::init();+ let app = cli::Rover::from_args();++ // attempt to create a new `Session` to capture anonymous usage data+ match Session::new(&app) {+ // if successful, report the usage data in the background+ Ok(session) => {+ // kicks off the reporting on a background thread+ let report_thread = thread::spawn(move || {+ // ignore errors because it is not in the critical path+ let _ = session.report();+ });++ // kicks off the app on the main thread+ app.run()?;
How would you add custom session information from the invocation of a command (like "this introspection request was for a federated graph") with this setup?
comment created time in 22 days
Pull request review commentapollographql/rover
+use url::Url;+use uuid::Uuid;++use std::fs::{self, File};+use std::io::Write;+use std::path::{Path, PathBuf};++use crate::SputnikError;++/// Report defines the behavior of how anonymous usage data is reported.+pub trait Report {+ /// converts the struct to a json blob.+ fn serialize_command(&self) -> Result<String, SputnikError>;++ /// checks if a user has enabled anonymous usage data.+ fn is_enabled(&self) -> bool;++ /// returns the endpoint that the data should be posted to.+ fn endpoint(&self) -> Result<Url, SputnikError>;++ /// returns the name of the tool, this is used to construct+ /// the User-Agent header.+ fn tool_name(&self) -> String;++ /// returns the version of the tool, this is used to construct+ /// the User-Agent header+ fn version(&self) -> String;++ /// constructs a user agent for the tool. by default, it calls+ /// self.tool_name() and self.version() to construct this.+ fn user_agent(&self) -> String {+ format!("{}/{}", self.tool_name(), self.version())+ }++ /// returns the location the tool stores a globally persistent+ /// machine identifier+ fn machine_id_config(&self) -> Result<PathBuf, SputnikError>;++ /// returns the globally persistent machine identifier
and writes it if not present
comment created time in 22 days
Pull request review commentapollographql/rover
+use thiserror::Error;++use std::io;++/// HoustonProblem is the type of Error that occured.+#[derive(Error, Debug)]+pub enum HoustonProblem {+ /// ConfigDirNotFound occurs when the default OS config can't be found.+ #[error("Could not determine default OS config directory.")]
Is there a way to make these messages more actionable?
comment created time in 22 days
Pull request review commentapollographql/rover
+# 🚀 Sputnik++Sputnik is a crate to aid in the collection of anonymous usage data for CLIs built in Rust.++## Overview++Sputnik declares the `sputnik::Session` struct which is used to capture information about a single command execution. example:++```sh+body:+ command: {"command":{"Config":{"command":{"Profile":{"command":"List"}}}}}
This structure will be hard to search / index within our backend. Does this only capture arguments and not flags? If so, why not a vec<String> or something more simple where the depth isn't variable?
comment created time in 22 days
Pull request review commentapollographql/rover
+use thiserror::Error;++use std::io;++/// SputnikError is the type of Error that occured.+#[derive(Error, Debug)]+pub enum SputnikError {+ /// IOError occurs when any given std::io::Error arises.+ #[error(transparent)]+ IOError(#[from] io::Error),
I have the same scaling questions about the from implementations here. Is this better than asking the calling code to do the conversion? I'm really not sure!
comment created time in 22 days
Pull request review commentapollographql/rover
+use thiserror::Error;++use std::io;++/// HoustonProblem is the type of Error that occured.+#[derive(Error, Debug)]+pub enum HoustonProblem {+ /// ConfigDirNotFound occurs when the default OS config can't be found.+ #[error("Could not determine default OS config directory.")]+ ConfigDirNotFound,++ /// ProfileNotFound occurs when a profile with a specified name can't be found.+ #[error("Profile {0} not found.")]+ ProfileNotFound(String),++ /// NoNonSensitiveConfigFound occurs when non-sensitive config can't be found for a profile.+ #[error("No non-sensitive config found for profile {0}.")]+ NoNonSensitiveConfigFound(String),++ /// TomlSerialization occurs when a profile's configuration can't be serialized to a String.+ #[error(transparent)]+ TomlSerialization(#[from] toml::ser::Error),
I'm a little suprised to see these implemented as HoustonErrors. Is that just to get the from casting so that we can use ?? I'm a little unsure of how well this will scale?
comment created time in 22 days
Pull request review commentapollographql/rover
+use thiserror::Error;++use std::io;++/// HoustonProblem is the type of Error that occured.+#[derive(Error, Debug)]+pub enum HoustonProblem {
👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼👏🏼
comment created time in 22 days
push eventapollographql/federation
commit sha 791809132a17e0e4f830e24dbf1d2eff24c135d9
Initial working implementation of execution This commit is a first take at porting over execution from the TypeScript implementation as well as surrounding scaffolding for a PoC server runtime and process manager. This is an initial stab for feedback and will be split up into multiple commits for review in different PRs around structure, execution, and basic server scaffold after testing is done.
commit sha 6e5bf0dcada99c92a2c99706124926d1a4e23662
add back in cargo lock after rebase
commit sha 5936e4ba93343e65beaeb248b7c637dc329b7f50
fix merge conflicts
push time in 22 days
push eventapollographql/federation
commit sha 791809132a17e0e4f830e24dbf1d2eff24c135d9
Initial working implementation of execution This commit is a first take at porting over execution from the TypeScript implementation as well as surrounding scaffolding for a PoC server runtime and process manager. This is an initial stab for feedback and will be split up into multiple commits for review in different PRs around structure, execution, and basic server scaffold after testing is done.
commit sha 6e5bf0dcada99c92a2c99706124926d1a4e23662
add back in cargo lock after rebase
push time in 25 days
startednagisa/rust_libloading
started time in a month
issue commentapollographql/apollo-cli
telemetry: report CLI usage anonymously
In the course of a panic of the CLI, we want a few things to happen:
- an actionable and friendly message to be sent to the user to tell them what went wrong and what steps they can take to fix the problem
- a way to report the issue to us if it keeps happening
- a report sent to us with internal information such as line numbers, stack trace, and env information automatically so that we can proactively fix issues as they arise instead of waiting on reports flowing into GitHub.
I think for error reporting we want all of these and something like sentry could give us the last item whereas jane's crate could give us nice user facing error messages and auto github links
comment created time in a month
issue commentapollographql/apollo-cli
telemetry: report CLI usage anonymously
for error reporting that isn't user facing
comment created time in a month
created tagapollographql/apollo-tooling
✏️ Tooling for development and production Apollo workflows
created time in a month
release apollographql/apollo-tooling
apollo-v2.31.0-darwin-x64.tar.gz 22.27MB
apollo-v2.31.0.tar.gz 10.14MB
released time in a month
release apollographql/apollo-tooling
apollo-v2.31.0-darwin-x64.tar.gz 22.27MB
apollo-v2.31.0.tar.gz 10.15MB
released time in a month
pull request commentapollographql/apollo-cli
oh dang I did not know you can do that! That is super cool. No pref either way but def adding this to my vim config
comment created time in a month
pull request commentapollographql/apollo-cli
@ashleygwilliams the docs infrastructure at Apollo is owned by the dx team and they have opted to go with Gatsby as their infrastructure. This isn't something that we really have a choice in, though if we have concerns/feedback we should give it to them! Because of that, I'm fine with this addition and we should document how to author docs here and link to our docs-docs (and probably improve them more)
comment created time in a month
pull request commentapollographql/apollo-cli
this release CI does not build a release for every commit
We have seen pretty big wins with per PR builds of other Apollo projects to allow for one off testing by community members / customers. Especially if we wired this up to the curl installer, it would make for a very easy curl https://install.apollo.dev/cli/pr/1234 | sh way to try out custom builds for teams wanting to test issues. We use this for apollo server / federation quite often.
comment created time in a month
pull request commentapollographql/apollo-cli
adds first version of release checklist
@EverlastingBugstopper this checklist leads me to believe when we add support for cargo/npm we should absolutely automate the release process of those registries along with the GitHub releases.
comment created time in a month
Pull request review commentapollographql/apollo-cli
adds first version of release checklist
+# Release Checklist++This is a list of the things that need to happen during a release.++## Build a Release++### Prepare the Changelog (Full release only)++1. Open the associated milestone. All issues and PRs should be closed. If+ they are not you should reassign all open issues and PRs to future+ milestones.+1. Go through the commit history since the last release. Ensure that all PRs+ that have landed are marked with the milestone. You can use this to+ show all the PRs that are merged on or after YYY-MM-DD:+ `https://github.com/issues?utf8=%E2%9C%93&q=repo%3Aapollographql%2Fapollo-cli+merged%3A%3E%3DYYYY-MM-DD`+1. Go through the closed PRs in the milestone. Each should have a changelog+ label indicating if the change is documentation, feature, fix, or maintenance. If+ there is a missing label, please add one. If it is a breaking change, also add a changelog - BREAKING label.+1. Choose an emoji for the release. Try to make it semi-related to something that's been included in the release.+1. Add this release to the `CHANGELOG.md`. Use the structure of previous+ entries. If you are releasing a beta or a release candidate, no official changelog is needed, but you're not off the hook! You'll need to write testing instructions in lieu of an official changelog.++### Update cargo manifest++1. Update the version in `Cargo.toml`.+1. Run `cargo update`.+1. Run `cargo test`.+1. Run `cargo build`.++### Update npm manifest and assets++1. Copy `README.md` to `npm/README.md`+1. Bump the version number in `npm/package.json`+1. `cd npm && npm install` _Note: This step will appear to fail, however its utility is re-building npm-shrinkwrap.json_++### Start a release PR++1. Create a new branch "#.#.#" where "#.#.#" is this release's version (release) or "#.#.#-rc.#" (release candidate)+1. Push up a commit with the `Cargo.toml`, `Cargo.lock` and `CHANGELOG.md` changes. The commit message can just be "#.#.#" (release) or "#.#.#-rc.#" (release candidate)+1. Request review from the Apollo GraphQL tooling team.++### Review++Most review comments will be about the changelog. Once the PR is finalized and approved:++1. If you made changes, squash or fixup all changes into a single commit.+1. Run `git push` and wait for CI to pass.++### Tag and build release++This part of the release process is handled by GitHub Actions, and our binaries are distributed as GitHub Releases. When you push a version tag, it kicks off an action that creates a new GitHub release for that tag, builds release binaries and attaches them to the release.++1. Once ready to merge, tag the commit by running either `git tag -a v#.#.# -m #.#.#` (release), or `git tag -a v#.#.#-rc.# -m #.#.#` (release candidate)+1. Run `git push --tags`.+1. Wait for CI to pass.++### Edit the release++After CI builds the release binaries and they appear on the [releases page](https://github.com/apollographql/apollo-cli/releases), click `Edit` and update release notes.
Is this needed with the changelog being added? Or is this for additional information?
comment created time in a month
Pull request review commentapollographql/apollo-cli
adds first version of release checklist
+# Release Checklist++This is a list of the things that need to happen during a release.++## Build a Release++### Prepare the Changelog (Full release only)++1. Open the associated milestone. All issues and PRs should be closed. If+ they are not you should reassign all open issues and PRs to future+ milestones.+1. Go through the commit history since the last release. Ensure that all PRs+ that have landed are marked with the milestone. You can use this to+ show all the PRs that are merged on or after YYY-MM-DD:+ `https://github.com/issues?utf8=%E2%9C%93&q=repo%3Aapollographql%2Fapollo-cli+merged%3A%3E%3DYYYY-MM-DD`+1. Go through the closed PRs in the milestone. Each should have a changelog+ label indicating if the change is documentation, feature, fix, or maintenance. If+ there is a missing label, please add one. If it is a breaking change, also add a changelog - BREAKING label.+1. Choose an emoji for the release. Try to make it semi-related to something that's been included in the release.+1. Add this release to the `CHANGELOG.md`. Use the structure of previous+ entries. If you are releasing a beta or a release candidate, no official changelog is needed, but you're not off the hook! You'll need to write testing instructions in lieu of an official changelog.++### Update cargo manifest++1. Update the version in `Cargo.toml`.+1. Run `cargo update`.+1. Run `cargo test`.+1. Run `cargo build`.++### Update npm manifest and assets++1. Copy `README.md` to `npm/README.md`+1. Bump the version number in `npm/package.json`+1. `cd npm && npm install` _Note: This step will appear to fail, however its utility is re-building npm-shrinkwrap.json_++### Start a release PR++1. Create a new branch "#.#.#" where "#.#.#" is this release's version (release) or "#.#.#-rc.#" (release candidate)+1. Push up a commit with the `Cargo.toml`, `Cargo.lock` and `CHANGELOG.md` changes. The commit message can just be "#.#.#" (release) or "#.#.#-rc.#" (release candidate)+1. Request review from the Apollo GraphQL tooling team.
Should we make a GitHub team for this?
comment created time in a month
Pull request review commentapollographql/apollo-cli
adds first version of release checklist
+# Release Checklist++This is a list of the things that need to happen during a release.++## Build a Release++### Prepare the Changelog (Full release only)++1. Open the associated milestone. All issues and PRs should be closed. If+ they are not you should reassign all open issues and PRs to future+ milestones.+1. Go through the commit history since the last release. Ensure that all PRs+ that have landed are marked with the milestone. You can use this to+ show all the PRs that are merged on or after YYY-MM-DD:+ `https://github.com/issues?utf8=%E2%9C%93&q=repo%3Aapollographql%2Fapollo-cli+merged%3A%3E%3DYYYY-MM-DD`+1. Go through the closed PRs in the milestone. Each should have a changelog+ label indicating if the change is documentation, feature, fix, or maintenance. If+ there is a missing label, please add one. If it is a breaking change, also add a changelog - BREAKING label.+1. Choose an emoji for the release. Try to make it semi-related to something that's been included in the release.+1. Add this release to the `CHANGELOG.md`. Use the structure of previous+ entries. If you are releasing a beta or a release candidate, no official changelog is needed, but you're not off the hook! You'll need to write testing instructions in lieu of an official changelog.++### Update cargo manifest++1. Update the version in `Cargo.toml`.+1. Run `cargo update`.+1. Run `cargo test`.+1. Run `cargo build`.++### Update npm manifest and assets
This part doesn't exist yet. Should we add it in when that gets added?
comment created time in a month
Pull request review commentapollographql/apollo-cli
adds first version of release checklist
+# Release Checklist++This is a list of the things that need to happen during a release.++## Build a Release++### Prepare the Changelog (Full release only)++1. Open the associated milestone. All issues and PRs should be closed. If+ they are not you should reassign all open issues and PRs to future+ milestones.+1. Go through the commit history since the last release. Ensure that all PRs+ that have landed are marked with the milestone. You can use this to+ show all the PRs that are merged on or after YYY-MM-DD:+ `https://github.com/issues?utf8=%E2%9C%93&q=repo%3Aapollographql%2Fapollo-cli+merged%3A%3E%3DYYYY-MM-DD`+1. Go through the closed PRs in the milestone. Each should have a changelog+ label indicating if the change is documentation, feature, fix, or maintenance. If+ there is a missing label, please add one. If it is a breaking change, also add a changelog - BREAKING label.+1. Choose an emoji for the release. Try to make it semi-related to something that's been included in the release.+1. Add this release to the `CHANGELOG.md`. Use the structure of previous+ entries. If you are releasing a beta or a release candidate, no official changelog is needed, but you're not off the hook! You'll need to write testing instructions in lieu of an official changelog.++### Update cargo manifest++1. Update the version in `Cargo.toml`.+1. Run `cargo update`.+1. Run `cargo test`.+1. Run `cargo build`.++### Update npm manifest and assets++1. Copy `README.md` to `npm/README.md`+1. Bump the version number in `npm/package.json`+1. `cd npm && npm install` _Note: This step will appear to fail, however its utility is re-building npm-shrinkwrap.json_++### Start a release PR++1. Create a new branch "#.#.#" where "#.#.#" is this release's version (release) or "#.#.#-rc.#" (release candidate)+1. Push up a commit with the `Cargo.toml`, `Cargo.lock` and `CHANGELOG.md` changes. The commit message can just be "#.#.#" (release) or "#.#.#-rc.#" (release candidate)+1. Request review from the Apollo GraphQL tooling team.++### Review++Most review comments will be about the changelog. Once the PR is finalized and approved:++1. If you made changes, squash or fixup all changes into a single commit.+1. Run `git push` and wait for CI to pass.++### Tag and build release++This part of the release process is handled by GitHub Actions, and our binaries are distributed as GitHub Releases. When you push a version tag, it kicks off an action that creates a new GitHub release for that tag, builds release binaries and attaches them to the release.++1. Once ready to merge, tag the commit by running either `git tag -a v#.#.# -m #.#.#` (release), or `git tag -a v#.#.#-rc.# -m #.#.#` (release candidate)+1. Run `git push --tags`.+1. Wait for CI to pass.++### Edit the release++After CI builds the release binaries and they appear on the [releases page](https://github.com/apollographql/apollo-cli/releases), click `Edit` and update release notes.++#### For Full Releases++1. Paste the current release notes from `CHANGELOG.md` into the release body.+1. Update the *title* of the release (not the tag itself) to include the emoji for the current release+1. Be sure to add any missing link definitions to the release.++#### For Release Candidates++1. CI should already mark the release as a `pre-release`. Double check that it's listed as a pre-release on the release's Edit page.+1. If this is a new rc (rc.0), paste testing instructions into the release notes.+1. If this is a rc.1 or later, the old release candidate testing instructions should be moved to the latest release candidate testing instructions, and replaced with the following message:++ ```markdown+ This beta release is now out of date. If you previously installed this release, you should reinstall and see what's changed in the latest [release](https://github.com/apollographql/apollo-cli/releases).+ ```++ The new release candidate should then include updated testing instructions with a small changelog at the top to get folks who installed the old release candidate up to speed.++## Publish++1. Hit the big green Merge button on the release PR.+1. `git checkout master` and `git pull --rebase origin master`++### Publish to crates.io (full release only)++**IMPORTANT: This step is the hardest to fix if you mess it up. Do not run this step for Release Candidates**.++We don't publish release candidates to crates.io because they don't (as of this writing) have a concept of a "beta" version.++1. Run `cargo test`
Since we don't have cargo/npm yet should we hold off on this? Or go ahead and add it in since we know we are doing this?
comment created time in a month
pull request commentapollographql/apollo-cli
@EverlastingBugstopper
The action does not (yet) automatically create the release with the complete entry from the changelog, the release must be modified after the release has been created by the action.
I thought it did do this with the changelog portions you added?
comment created time in a month
issue commentapollographql/apollo-cli
telemetry: report CLI usage anonymously
@EverlastingBugstopper another approach we could consider taking would be to bundle something like sentry with Rover since this is actually a built binary instead of javascript so using an API key based tool like that would be better than before. Thoughts?
comment created time in a month
issue commentapollographql/apollo-cli
telemetry: report CLI usage anonymously
@EverlastingBugstopper my concern with reporting errors is that they can contain user identifiable information or sensitive information like keys accidentally which we don't want to have in our system. I like the idea of a success/error rate for the CLI but we should be careful to not have any user data come into the telemetry system
comment created time in a month
push eventapollographql/federation
commit sha d32aa918a830d9daa3abd87dedd8b6400c698bd3
basic control from stdin
commit sha 9650792ebc25b113098754707a7232f8ede1377b
support nested flatten nodes
commit sha 3361d1170d4802ac230185e4f6ca7f725dde32f5
reduce deep clone usage in flatten node
push time in a month
push eventapollographql/federation
commit sha 453fc4e933eae6bb1c63c795f1faadb1b5ecdbeb
first pass at adding docs for the detach directive
push time in a month
push eventapollographql/federation
commit sha b38d91b245cb41e12d7c52cd7a7327cedebfe62f
try for simple url link
push time in a month
push eventapollographql/federation
commit sha d3f82969ed66e4a40f0c4fc91c8554dd1affc9eb
Fix file names on images
push time in a month
push eventapollographql/federation
commit sha f9d662494995936df1fa4e4161a1eb3919d78e4c
adjust headers on page
push time in a month
push eventapollographql/federation
commit sha 35d3b2b0e1d84046c06f2af6ea522f55cb10d32f
adjust formatting of execution docs
push time in a month
PR opened apollographql/federation
@JakeDawkins @abernix This is a PoC to see if this will work. Not sure if this is where this should be or not but I can't get gatsby to work on WSL because it requires chrome to be present to I'm opening this PR to use the deploy previews. Feel free to close if this isn't the right place for these docs.
pr created time in a month
create barnchapollographql/federation
branch : jbaxleyiii/add-detach-docs
created branch time in a month
push eventapollographql/federation
commit sha a1ded727928d9d8e75b18f8f348039afcff1076e
Move Apollo Federation into core (apollographql/apollo-server#2742) This PR (though large) is comprised of months of work on Apollo Federation, a new way to build a federated graph. This commit brings the two core packages @apollo/federation and @apollo/gateway as well as documentation for building a federated graph Co-authored-by: Martijn Walraven <[email protected]> Co-authored-by: Jake Dawkins <[email protected]> Co-authored-by: Jesse Rosenberger <[email protected]> Co-authored-by: Trevor Scheer <[email protected]> Co-authored-by: James Baxley <[email protected]> cc @martijnwalraven @JakeDawkins @abernix @trevor-scheer @jbaxleyiii Apollo-Orig-Commit-AS: apollographql/apollo-server@408e9a99b7efb1f18a292c92b334ad999ef4a04b
commit sha ba54f7c3edc1ec5b84f167879416b988b217942f
Adjust `tsconfig.test` files for new project home/structure. Apollo-Orig-Commit-AS: apollographql/apollo-server@bdf2217b713d1836426b221d0581834737153d7b
commit sha e93d8d4bfd3ccd04ca975918dcd5a22f7d025484
Add `apollo-server-env` to modules which use `Object.entries`. For now, this is the solution to getting Node.js 6 to pass. But we should strongly consider removing these soon. Apollo-Orig-Commit-AS: apollographql/apollo-server@ae109d7489a97b7d8562d88cf377d637c49160fc
commit sha a5bf7c9b0f77f944e10af422b8331ee1325d4623
Apollo Gateway requires Node.js 8, ideally. Apollo-Orig-Commit-AS: apollographql/apollo-server@4e128265a1ddd2e171f1dc5c3b9b3311a6eb6ae7
commit sha 8be6a93bead45ddb9f2688c9fa0fce597fb4608d
Publish - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@fdcd0d29c14a76bd70931c7bb5961b49a4f84d0e
commit sha d102b016a5f545dbce32c214cf2bf20548272796
Promote to RC. Apollo-Orig-Commit-AS: apollographql/apollo-server@10c727b9d59f027e58c5acc17d1ecb85b479e0c7
commit sha d07d719214e691e52f843874887cbbb725f5f392
Publish - [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@cfdac5365781a2459b3daea5dcc6769990cbd666
commit sha 1a641b94b0aae9e667908d7afa4adaa64e4d00de
Empty commit for final release. Apollo-Orig-Commit-AS: apollographql/apollo-server@f6319d2f20ff2c8d0b7bf474342c9ea9cb264a22
commit sha ab8dfef2e34af7cacf9cf9c7d5211697e06dd91f
Publish - [email protected] - [email protected] - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@dcab64689dec2d00a9c6d302c7c05c5ab847e855
commit sha a72e0317660691ea18e7cfa8ac2453c56b1cc199
Publish - [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@acaac3c64a050eac02848cffc32feb514825b672
commit sha 5338e09a1d6e5f0851a2df1b8bba4e2de6a46c3a
Preparation for final 2.6.1 release. Empty commit to let Lerna know that _something_ has changed, even if it is just the version that I'm _about_ to input and it doesn't know about yet! Apollo-Orig-Commit-AS: apollographql/apollo-server@08d73edb83b04ff86a040a8c608bca876ae7a71c
commit sha fadb013a7dcf5a340e9297961cfada939c5512ad
Publish - [email protected] - [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@77b044169d61dd50f8426a1ba87710cf38fefd36
commit sha 8f7ffe43b05ab8200f805697c6005e4e0bca080a
Ignore __proto__ fields in deepMerge() (apollographql/apollo-server#2779) This resolves a security issue within @apollo/gateway. The deepMerge function is open to a known attack vector called prototype pollution. Prototype pollution allows a user to "pollute" Object.prototype, thereby polluting all Objects with Object.prototype in their prototype chain. This function is currently only in use by @apollo/gateway. Apollo-Orig-Commit-AS: apollographql/apollo-server@69e4854543848f289f4a6ddcb9f962743432398c
commit sha d8d0a506bb6a049e3aad6ce24154a3d03294f2fb
Publish - @apollo/[email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@e113127b1ff9802de3bc5574bcae55256f0ef656
commit sha 7251544eab3ea31a93163276f157e9e3c5dac65a
[Federation] Normalize SDL in a normalization step before validation (apollographql/apollo-server#2771) Currently, we perform transformations to normalize an individual service's SDL during composition. One of the normalizations (`@extends` directive) should actually be performed before composition happens for simplicity. The result of this realization was to pull out SDL normalization into a separate step which happens before composition. Noteworthy changes: * Filter @extends directives after transforming to `extend type` (they're extraneous) * Perform schema normalizations before composition Apollo-Orig-Commit-AS: apollographql/apollo-server@0a9af35b15ef58e4da388eaf3ca190eceb432ed2
commit sha fee86fe4d0aedcffc14577adce5b61509fec700e
Publish - @apollo/[email protected] - @apollo/[email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@1209839c01b4cac1eb23f42c747296dd9507a8ac
commit sha 18fbd0671bcb21bd39e99421c51ba70e6754283f
Publish - [email protected] - [email protected] - [email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@4fdf6f2aa2f14854b54b0d6de7d477afc7702916
commit sha 197159b998a132b15c0986ae711a3b627abe7f4a
[Federation] Add error codes to snapshot results (apollographql/apollo-server#2785) Introduce error codes to snapshot results for validations in order to ensure their stability. Created a new serializer for GraphQLErrors in order to display the error codes we attach to GraphQLError.extensions.code. This serializer should be used wherever we're displaying GraphQLErrors that we create. Apollo-Orig-Commit-AS: apollographql/apollo-server@8ad52d428773896df11cf32887258a6ca7731e6f
commit sha 1bfcd01b473b7f10824099964e21ba213901800f
[Federation] Relax constraints of root operation type names in validation (apollographql/apollo-server#2783) Relax constraints against default root operation names Currently, if any schema definition or extension is provided, the use of _all_ default operation names are banned. The desired behavior is actually to permit them when it's appropriate. This change now permits the following examples: ----------------- schema { query: Query } type Query {...} ----------------- schema { query: Query mutation: RootMutation } type Query {...} type RootMutation {...} ----------------- Apollo-Orig-Commit-AS: apollographql/apollo-server@7cd1ba4c82fdddafa700ab696152a85db93a8fc7
commit sha ba12d6632ec1db75bc616a84af3f0d135ad0a58d
Update changelog for gateway release Apollo-Orig-Commit-AS: apollographql/apollo-server@2346a6cf39d8ed9934096338964506d4c97ff24c
push time in a month
PR opened apollographql/federation
What this is
This is a spike of a porting the JavaScript query executor which takes the query plan generated by the new Rust query planner and does a simple http fetch to the federated service and merges the data back together. This is not something we should intend to merge, rather it was a spike to see where things will be tricky as we work to do the port genuinely and where we could slice things for smaller deliverables.
What do I do with this?
What I would to get out of this exercise is a shared understanding of some of the footguns which may lie ahead, what a common data structure needs to look like for the executor, and some of the challenges (and opportunities) in moving from a single threaded environment to a multi-threaded one. So
- Don't review this for code quality / idiomatic Rust code. Its not that I'm not looking to improve my Rust, but rather this is a sketch of an idea not a real thing.
- Do read through the main executor. Below is a more detailed guide of what is interesting
- Do ask questions about the data structures, general shape of the problem.
- Don't focus on the http parts (tide, parsing of the response, etc). This was just for local testing.
Detailed Review Notes
- The JS query executor relies heavily on two things to be successful. First, the single threaded nature of JavaScript and second, the ease of interior mutability within that thread. In particular, the
FlattenNodeand theFetchNodeboth mutate the result sink in a way that works if there is only one thread and a shared reference to the sink. For example, flattenResultsAtPath mutates the results while creating a zip for subsequent nodes to work on. This is really hard / not what we should do in a world where you have multiple threads and interior mutability isn't really the way to go. RwLockis incredible. In the executor we need to be able to read from a shared reference at multiple times without block access to the data but block on writes. This is important because prior to sending a fetch we need to read the results to generate variables for downstream requests and we don't want to block on this for every request that is being formed. However, we do need to block on writes so that reads get the updated data correctly. AMutexblocks on both butRwLockgets us just what we wanted. You can see where we create the lock and an example where we write back to it- deep merging of json isn't easy. I found a library but am not 100% sure it actually does what we want. It may or may not be why parallel flatten nodes don't work
- Instead of manually forking threads, I am relying on futures to manage promises for me. I'm not sure if this is actually doing what I want it to do but it behaves like
Promise.allSettledwhich is similar to the existing one. Maybe we should go more all in on threads here, not sure. - We are going to need to do some cloning when it comes time to send requests. Mainly of the variables because these could be used across multiple requests to the executeNode can't take ownership of them. I don't think this is a problem but wanted to flag it here for discussion.
- Some idioms in JS are just not possible in Rust.. This is on the whole a good thing and it has already helped to improve this implementation but don't count on a direct port being the same shape in each part.
- We will need to figure out lifetimes / ownership of the schema within threads so it can be created outside of a request. I didn't worry about that right now but that is definitely something we will need to do
Suggested next steps
I think after an initial read through, a pairing session could be a helpful way to talk through this. Overall I'm quite thrilled at how quickly this came together and it makes me even more excited about when we tackle this for real. Let me know if you have any questions! 👍
pr created time in a month
create barnchapollographql/federation
branch : jbaxleyiii/gateway-spike
created branch time in a month
startedpipedrive/graphql-schema-registry
started time in 2 months
release apollographql/apollo-tooling
apollo-v2.30.3-darwin-x64.tar.gz 22.05MB
apollo-v2.30.3.tar.gz 9.93MB
released time in 2 months
push eventapollographql/spaceport
commit sha 16994211beb734db443bdd9f7e0eb6a8a0afcf50
update security warning deps
push time in 2 months
push eventapollographql/spaceport
commit sha 52f5586ea0197261dfbd2022efd094a0b0616547
fix link to images
push time in 2 months
created repositoryapollographql/spaceport
Cloudflare worker for distribution of the Apollo CLI
created time in 2 months
issue closedapollographql/apollo-server
DISCUSSION: How to handle cross-cutting/shared concerns in Federation (Summit 7/2020)
Context
In the Federation topic room, we discussed the desire to establish strong patterns around shared concerns:
- Value Types (non-entities)
- Scalars
- Enums
Experience
We have shared experience here that could help others:
- Using shared libraries
- Using "layers" of schema or a non-planable set of schema
- What can you share about your experience?
Make this an "Impossible State"
- What could we see in Federation that would reduce the risk of this shared concern?
- Are there extensions to Federation that could help?
closed time in 2 months
jhampton
issue commentapollographql/apollo-server
feat(gateway): CSDL fields arguments should be parseable as-is
@trevor-scheer this does seem pragmatic and should probably encourage us to revisit the current FieldSet abstraction (cc @queerviolet). I don't love that we will have a differing authoring format from output format but since we support such a limited set of what we support in FieldSets (just fields, not fragments or variables) I think this is probably a safe thing for the internal IR that is the CSDL
comment created time in 2 months
startedvasturiano/3d-force-graph
started time in 2 months
startedqueerviolet/constellation.talk
started time in 2 months
release apollographql/apollo-tooling
apollo-v2.30.2-darwin-x64.tar.gz 21.79MB
apollo-v2.30.2.tar.gz 9.66MB
released time in 3 months
Pull request review commentapollographql/apollo-cli
[WIP] preliminary authentication commands + env var support
+# Authentication++```+rover-auth 0.0.0+🔐 Manage authentication++USAGE:+ rover auth <SUBCOMMAND>
I would love to see a discussion about the name for people to give feedback on it! I don't know / think this PR is the right place to do that given its size though
comment created time in 3 months
Pull request review commentapollographql/apollo-cli
[WIP] preliminary authentication commands + env var support
+use anyhow::{Error, Result};+use console::{self, style};+use rover_config as config;+use structopt::StructOpt;++#[derive(Debug, StructOpt)]+pub struct Auth {+ #[structopt(subcommand)]+ command: Command,+}++#[derive(Debug, StructOpt)]+pub enum Command {+ /// 🔑 Use an Account or Graph API Key+ ApiKey,+}++impl Auth {+ pub fn run(&self) -> Result<()> {+ match self.command {+ Command::ApiKey => {+ let api_key = get_api_key()?;+ config::set_api_key(api_key)?;+ match config::get_api_key(None) {+ Ok(_) => {+ log::info!("Successfully saved API key.");+ Ok(())+ }+ Err(e) => Err(e),+ }+ }+ }+ }+}++fn get_api_key() -> Result<String> {+ let term = console::Term::stdout();+ log::info!(+ "Go to {} and create a new Personal API Key.",+ style("https://engine.apollographql.com/user-settings").cyan()
style("https://studio.apollographql.com/user-settings").cyan()
comment created time in 3 months
Pull request review commentapollographql/apollo-cli
[WIP] preliminary authentication commands + env var support
+[package]+name = "rover-config"+version = "0.1.0"+authors = ["Ashley Williams <[email protected]>"]
Can we change this to the same email we used in the rust repo (the oss email)
comment created time in 3 months
Pull request review commentapollographql/apollo-cli
[WIP] preliminary authentication commands + env var support
+# Authentication++```+rover-auth 0.0.0+🔐 Manage authentication++USAGE:+ rover auth <SUBCOMMAND>++FLAGS:+ -h, --help Prints help information+ -V, --version Prints version information++SUBCOMMANDS:+ api-key 🔑 Use an Account or Graph API Key+ help Prints this message or the help of the given subcommand(s)+```++For many of the CLI operations, you will not need to authenticate at all!++However, to use Apollo Studio services, such as checks, either in local+development or in CI, you'll want to grant the CLI permission to perform a set+of operations on your graphs. You can do this via API tokens.++Currently, there are 2 levels of permissions one can generate:++| Type | Generatable by | Perms | Recommended Use |+|---------|---------------------|-------------------------------|---------------------------|+| Account | Apollo Studio User | Same as the account | Local development machine |+| Graph | Apollo Studio Admin | Full perms for a single graph | CI |++You can authenticate the CLI via a command or an environment variable, using+either type of token. ++**Environment variables take precedence over the `auth` command. This means +that if you set an enviroment variable, it will override any configuration+a previously run `auth` command set.**++## Commands++```+rover auth api-key+[INFO] Go to https://engine.apollographql.com/user-settings and create a new Personal API Key.
We don't want to use engine anywhere in the new CLI. This should be studio.apollographql.com anywhere that is engine
comment created time in 3 months
Pull request review commentapollographql/apollo-cli
[WIP] preliminary authentication commands + env var support
+use rover::*;++use anyhow::Result;+use structopt::StructOpt;++fn main() -> Result<()> {+ logger::init();++ let cli = cli::Apollo::from_args();+ log::debug!("Command structure {:?}", cli);+ cli.run()?;+ Ok(())
What about the number exit codes? Did we not carry that over or will that come later?
comment created time in 3 months
startedorogene/orogene
started time in 3 months
issue commentapollographql/rust
Directives for SDL representation of composed schema
@abernix our thought was when we are ready to remove the restriction of single type ownership, we remove that annotation all together
comment created time in 3 months
startedapollographql/apollo-cli
started time in 3 months
startednrc/graphql
started time in 3 months
startedashleygwilliams/cargo-brrr
started time in 3 months