Unexpected behavior in apollo service check with service name set in apollo.config.js

[kryptonat]

Intended outcome:

Given that you can set the service name and endpoint in apollo.config below

apollo-tooling/packages/apollo-language-server/src/config/config.ts

Lines 131 to 135 in 9ffe78d

	export class ApolloConfig {
	public isClient: boolean;
	public isService: boolean;
	public engine: EngineConfig;
	public service?: ServiceConfigFormat;

apollo-tooling/packages/apollo-language-server/src/config/config.ts

Lines 108 to 112 in 9ffe78d

	export interface ServiceConfigFormat extends ConfigBase {
	name?: string;
	endpoint?: Exclude<RemoteServiceConfig, "name">;
	localSchemaFile?: string | string[];
	}

I would expect apollo service:check or apollo service:push to use these variables (specifically service name and endpoint) set in the config. Especially treating the service name in the config to be the same as the setting the serviceName flag i.e. it provides the name of the implementing service for a federated graph and indicates that the schema is a partial schema from a federated service

Actual outcome:

> yarn apollo service:check --serviceName='serviceA' --endpoint='http://localhost:3000/graphql'
  ✔ Loading Apollo Project
  ✔ Found 0 graph composition errors for service serviceA on graph SomeGraphName@current

is not equivalent to

> yarn apollo service:check -c apollo.config.js
  ✔ Loading Apollo Project
  ✔ Validating schema against metrics from variant current on graph SomeGraphName@current

where apollo.config.js contains

module.exports = {
  service: {
    name: 'serviceA',
    endpoint: {
      url: 'http://localhost:3000/graphql',
    },
  }
};

It appears the service commands do not parse service name from the apollo.config at all and only uses the value set in flags

apollo-tooling/packages/apollo/src/commands/service/check.ts

Line 334 in ba640f6

taskOutput.serviceName = flags.serviceName;

How to reproduce the issue:
See above for an example

Versions

apollo/2.27.3 darwin-x64 node-v12.14.0

[kryptonat]

From doing a bit more reading (specifically at the PR's in [email protected]), it appears the value of config.service.name is interpreted as the graph ID, and not the service name within the federated schema(?)