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

Tests are broken (access denied to "communal testing project") #987

Open
HoldYourWaffle opened this issue Nov 6, 2023 · 0 comments · May be fixed by #988
Open

Tests are broken (access denied to "communal testing project") #987

HoldYourWaffle opened this issue Nov 6, 2023 · 0 comments · May be fixed by #988

Comments

@HoldYourWaffle
Copy link
Contributor

HoldYourWaffle commented Nov 6, 2023

Expected Behavior

Running the tests on the master branch according to the instructions should pass with flying colors.

Actual Behavior

A bunch of tests fail :(

So far I have identified 4 separate issues:

  1. The documentation never mentions needing to run npm link after uninstalling the local version of clasp (d9bb573)
  2. Forgetting to define the SCRIPT_ID and/or PROJECT_ID environment variables fails silently (29b925e)
  3. The HOME environment variable does not exist on Windows, resulting in an incorrect CLASP_PATHS.rcGlobal (0c3081c)
  4. The SCRIPT_ID mentioned in the instructions seems to not be publicly accessible, leading to errors like this:
Could not find script.
Did you provide the correct scriptId?
Are you logged in to the correct account with the script?
Waiting for the debugger to disconnect...

Trying to access this script on the web (unsurprisingly) gives an "access denied".

Steps to Reproduce the Problem

  1. Clone this repository.
  2. Follow the instructions.

Specifications

  • Node version (node -v): v20.8.1
  • Version (clasp -v): 551000b
  • OS (Mac/Linux/Windows): Windows

Fixes

I opened PR #988 with fixes for the first three issues, but the last one is a bit more involved.
Regardless of permission issues, I feel like it's a little strange to have one "communal project" to use for tests, sounds like a recipe for trouble.
Perhaps it's a good idea to refactor the tests to use the multi-dev workflow described in #921 (comment)? I've been meaning to work on improvements for this workflow, this could be a good excuse to finally actually do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant