lint: fix camelCase

[casperdcl]

fixes #547

• The first commit is programmatically generated.
  • NB: don't squash-merge (to keep bot commit separate)
• deDe-camel
• The actual commits to check are https://github.com/iterative/cml/compare/7741a6f...6b28b84?w=1. In particular, my handling of:
  • rm-watermark
  • commit-sha
  • mime-type
  • head-sha
  • user-name
  • user-email
  • gitlab-uploads
  • startup-script
  • ssh-private
  • spot-price
  • idle-timeout
  • hdd-size
  • cloud-ssh-private-visible
  • pipe-args
  • git-url-parse
  • tf-resource

which is annoying due to yargs/yargs#1679

Snake is dead. Snake? Snake! SNAKE!

[DavidGOrtega]

lets try /tests first

[casperdcl]

Where's this --tf_resource flag from? https://gitlab.com/iterative.ai/cml/-/jobs/1283674644#L7031

[0x2b3bfa0]

Where's this --tf_resource flag from?

You've discovered the arcanes of the Terraform Provider 🧙🏼‍♂️

[0x2b3bfa0]

The provider is tightly coupled to CML, so we need to preserve backwards compatibility with the old underscore option for now.

[0x2b3bfa0]

Looks good to me, including fc5a0ab!

[casperdcl]

/tests

[DavidGOrtega]

@0x2b3bfa0

Looks good to me, including fc5a0ab!

why fc5a0ab looks good?
It has saved a decent amount of headaches in the past.
A common GITHUB_TOKEN can access the api but not the workflows api. If the token is not set it CML will tell first and if the token is set most probable error, having into account that GITHUB_TOKEN is the default token that is probably set, is that the token has no rights to do that. If not set that way is the error descriptive enough for us just to know or at least to hint it?

[0x2b3bfa0]

The issue with the current approach is that we're outputting the following message no matter what the actual error is:

Error: REPO_TOKEN does not have enough permissions to access workflow API

Removing the catch-all block, we would get instead this slightly more opaque message in the case you describe:

RequestError [HttpError]: Resource not accessible by integration

It's not as explicit as the previous message, but at leaset it won't mask unrelated errors behind the same description.

[casperdcl]

Ah FYI I don't intend to include fc5a0ab in this PR (will revert and leave for another issue) - it was a debug commit and clearly failed as I later realised that the / tests command incorrectly uses an NPM-release rather than the current state of the code so completely ignores fc5a0ab anyway. Which is yet another issue to be addressed elsewhere.

In any case the / tests command appears to be commented as:

cml/.github/workflows/checkbot.yml

Line 6 in 3cbbce0

# check that CML container builds properly

in which case it is successful (the docker image does indeed build successfully, and the later failure is unrelated to this PR).

I propose to merge without fc5a0ab. Any objections?

[DavidGOrtega]

The issue with the current approach is that we're outputting the following message no matter what the actual error is:

As I say the most probable error at that point specially in the CI is that. The CI is going to provide always a GITHUB_TOKEN.

We could make the question or suggest the error like many others do to hint.

This normally means .... or Does your token have workflow permissions?

But as I say its going to be very rare that the error is not that. It is even always telling you the truth.
If you miss to setup a proper token its correctly telling you that the token, even incorrect one, has no permissions to do such thing

[DavidGOrtega]

Caan we please squash and merge? 🙏

[casperdcl]

@DavidGOrtega I've removed that debug commit (we should leave it for another issue) - have you reviewed and are you happy with this PR as-is?

[DavidGOrtega]

tf-resource what happened to it?

[DavidGOrtega]

👍