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

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

Open
billwert opened this issue Feb 20, 2024 · 4 comments
Assignees
Labels
TypeSpec Issues or feature requests for tooling to support TypeSpec (Cadl)

Comments

@billwert
Copy link
Contributor

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>
@github-actions github-actions bot added the needs-triage This is a new issue that needs to be triaged to the appropriate team. label Feb 20, 2024
@catalinaperalta
Copy link
Member

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
Copy link
Member

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

@billwert
Copy link
Contributor Author

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

@catalinaperalta
Copy link
Member

catalinaperalta commented Feb 21, 2024

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.

@catalinaperalta catalinaperalta self-assigned this Feb 21, 2024
@catalinaperalta catalinaperalta added TypeSpec Issues or feature requests for tooling to support TypeSpec (Cadl) and removed needs-triage This is a new issue that needs to be triaged to the appropriate team. labels Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TypeSpec Issues or feature requests for tooling to support TypeSpec (Cadl)
Projects
None yet
Development

No branches or pull requests

2 participants