search

Azure / azure-sdk-tools

Tools repository leveraged by the Azure SDK team.
MIT License
110 stars 174 forks source link

tsp-client fails when using a local typespec project with commit hashes that aren't on the remote #7721

Open billwert opened 7 months ago

billwert commented 7 months ago

It appears tsp-client expects the value in tsp-location.yaml to point to a live hash on github. I am using tsp-compile to initialize a new library. I'm working from a local checkout of a PR into azure-rest-api-specs that I have made a commit to. I hit this failure:

Found emitter package @azure-tools/typespec-java
SDK initialized in D:/source/azure-sdk-for-java/sdk/eventgrid/azure-messaging-eventgrid-systemevents/sdk/eventgrid/azure-messaging-eventgrid-systemevents
Error: fatal: remote error: upload-pack: not our ref fa98e8d88df580b0a560143da8166d859255056d
fatal: remote error: upload-pack: not our ref fa98e8d88df580b0a560143da8166d859255056d
fatal: remote error: upload-pack: not our ref fa98e8d88df580b0a560143da8166d859255056d
fatal: remote error: upload-pack: not our ref fa98e8d88df580b0a560143da8166d859255056d
fatal: reference is not a tree: fa98e8d88df580b0a560143da8166d859255056d

repro steps (I think): 1) Make a local sync of some typespec project 2) Make a change to that project and commit it 3) run tsp-client init -c <path to local project> --repro Azure/azure-rest-api-specs --commit <local commit>

catalinaperalta commented 7 months ago

Thanks for reaching out about this @billwert! In this case I dont think you want to use tsp-client init since you've already initialized your project in the repo. tsp-client init should only be run once to initialize an SDK project, after that you would typically just run tsp-client update.

It seems like in this case you should be using: tsp-client update --local-spec-repo <path to TypeSpec specification directory where tspconfig.yaml file is located>. This command will use your local spec clone to sync and generate.

Please note that I am working on adding more examples to the README to show various usages for tsp-client. So there will be more examples to use. In case you havent gone though it, here is a link to the npm module with more information on the tool: https://www.npmjs.com/package/@azure-tools/typespec-client-generator-cli?activeTab=readme

catalinaperalta commented 7 months ago

I'll keep this issue open for tracking to improve the command descriptions in the README.

billwert commented 7 months ago

Hey! The target directory did not exist in this case and it was the first time I had run init for it.

catalinaperalta commented 7 months ago

Ah I see, this line in the output had caught my eye so realized there was also an issue when running the init: SDK initialized in D:/source/azure-sdk-for-java/sdk/eventgrid/azure-messaging-eventgrid-systemevents/sdk/eventgrid/azure-messaging-eventgrid-systemevents .

About the local commit, tsp-location.yaml is meant to help with versioning control for specs checked in upstream in the azure-rest-api-specs repo, so it's not really meaningful to put a local commit in that file (could also lead to some issues if the file is ever accidentally checked in with a local commit since we do run CI checks based off of the contents of tsp-location.yaml). If this is a dev scenario where we're actively testing some TypeSpec changes locally before we check them into the specs repo, then we should just refer to the local spec clone and iterate based on those changes. So if you have some work your testing on a local clone of the spec repo, then we would just use tsp-client update --local-spec-repo <path to the TypeSpec project in the local clone>.

NOTE: you still need to have a tsp-location.yaml under your SDK project directory to indicate important information such as additionalDirectories if relevant to your project.