Replace promote command with swagger import

[schovi]

Instead of workflow:

Swagger file -> swagger import + blueprint -> DEV
DEV -> promote -> QA
QA -> promote -> PRD

we can do:

Swagger file -> swagger import + blueprint -> DEV or QA or PRD

1. Each environment can have a separate blueprint, but it will cost a lot of work on maintaining.
2. Or it can share the same blueprint with some new properties which will be merged over default one:

endpoint:
  timeout: 10
  methods:
    - name: "Some method"
environment:
  DEV:
    endpoint:
      name: *:DEV *
      publicDomain: dev.adidas.com

  QA:
    endpoint:
      name: *:QA *
      timeout: 5
      publicDomain: qa.adidas.com

then it can be called as
mashery-toolbet swagger-import swagger.yaml --blueprint="blueprint.yaml" --env="QA"

[rathonit1]

@schovi yeh, but instead of merging.
Idea is similar to how we create DEV. We can create QA set, while maintaining separate swagger file.

with following command :
mashery-toolbelt swagger-import 11.yaml --blueprint=ServiceAPI_blueprint-QA.yml --organization='playground'
--name="*:QA (Demo) " --serviceName="(Demo):QA (Demo) *" --multiMethodEndpoint

& It works as expected.
I think you have some better plan on this with point 2.

[schovi]

@rathonit1 this came from the discussion with @oonovak and as we mentioned elsewhere we want to transfer all command arguments into blueprint.

[schovi]

@rathonit1
Idea of merging all together with swagger import and package creating

endpoint:
  timeout: 10
  methods:
    - name: "Some method"

package:
  name: "My new package"
  plans:
    - name: "My new plan"
      # services: This does not makes sense when we are already in kontext of service
      endpoints: "*"
      methods: "*"

environment:
  DEV:
    name: *:DEV * # We can have globally replacer for all name properties ?
    endpoint:
      name: *: SPECIAL DEV *
      publicDomain: dev.adidas.com

  QA:
    endpoint:
      name: *:QA *
      timeout: 5
      publicDomain: qa.adidas.com
    package: ....

There are endless possibilities how to sew it together. We can do many assumptions like there will be just on plan in package etc.
I think there are 2 ways

1. Keep it easy, straightforward but with more writing. That means we will keep separated importing of swagger and creating of package
2. Make it simple, but with a lot of "magic" behind and creating something really different than Mashery data structures. (example above)

[rathonit1]

@schovi , to make a note, we should include issues#19 in this release, to not delete anything in case swagger file changes, even with name and endpoints are not changed.. as we don't know which package is using particular endpoint....