`TOWER_COMPUTE_ENV` environment variable

[ewels]

I love that the access token, endpoint and workspace can be set in environment variables. Could the compute environment also be set in the same way?

[ewels]

Also the --help text says [default: primary workspace] when I guess it should probably read [default: primary compute environment]

[ewels]

Having TOWER_API_ENDPOINT as an environment variable would be another good one.. (sorry for the messy issue)

[jordeu]

Yes it should say "primary compute environment".

The TOWER_API_ENDPOINT it is already implemented.

[ewels]

The TOWER_API_ENDPOINT it is already implemented.

Right, sorry too much multitasking and not enough coffee 🤦🏻

[ewels]

Ok this is terrible issue manners sorry, but I'm running late so doing this as I go along.. Would it be possible to ignore these environment variables if empty?

$ tw info

    Details
    -------------------------+----------------------
     Tower API endpoint      | https://api.tower.nf
     Tower API version       | 1.7.0
     Tower version           | 21.10.15
     CLI version             | 0.4 (b163c11)
     CLI minimum API version | 1.7
     Authenticated user      | core

    System health status
    ---------------------------------------+------------------
     Remote API server connection check    | OK
     Tower API version check               | OK
     Authentication API credential's token | OK

$ export TOWER_API_ENDPOINT=
$ tw info

    Details
    -------------------------+-------------------------
     Tower API endpoint      |
     Tower API version       | UNDEFINED
     Tower version           | UNDEFINED
     CLI version             | 0.4 (b163c11)
     CLI minimum API version | 1.7
     Authenticated user      | UNDEFINED

    System health status
    ---------------------------------------+-------------------------
     Remote API server connection check    | FAILED
     Tower API version check               | UNDEFINED
     Authentication API credential's token | UNDEFINED

    Tower API URL  it is not available (did you mean /api?)

[ewels]

Context: https://github.com/nf-core/tower-action/pull/3 (the action always sets the env variable, even if it's not provided)

[jordeu]

To set it as a command line option with --url overrides the env variable. Does it work for you?

[ewels]

Yes I was about to try something like that, but then I thought it would be easier to set a default value in the action input. Then it just supplies api.tower.nf to the env variable if nothing else is given. Seems to work fine..

[ewels]

Note that I haven't tried with an empty workspace input yet. That might be trickier. I guess I'll need to use the command line flag there (not a big issue, I just like the env vars as it fits well with actions and keeps the command clean).

[jordeu]

An empty TOWER_WORKSPACE_ID fails with a "is not a long" error.

When you do not set the workspace it means that you want to use the "personal workspace". On this variable I would agree that to have a way to explicitly define that you want to use the "personal workspace" makes sense.

Some ideas:

• TOWER_WORKSPACE_ID = -1
• TOWER_WORKSPACE_ID = 0
• TOWER_WORKSPACE_ID = null
• TOWER_WORKSPACE_ID = none

[pditommaso]

Think empty should be ignored. Is this a CLI or BE behaviour?

[jordeu]

Ok, I've checked and nextflow fallbacks to use the default value if TOWER_WORKSPACE_ID or TOWER_API_ENDPOINT is defined but empty.

Let's do the same at CLI.

[ewels]

Sounds great 👏🏻

Apologies again for my poor issue etiquette yesterday, should I make a new issue for this? The original topic in this issue is about creating a new TOWER_COMPUTE_ENV env var for the cli.

[gwright99]

IMHO explicit is better than implicit. I think it's good to have the variable present and configured (even if it's using the default value) as this provides more self-documentation in the config file.

[jordeu]

IMHO explicit is better than implicit. I think it's good to have the variable present and configured (even if it's using the default value) as this provides more self-documentation in the config file.

I agree with you @gwright99 . The thing here is that a workspaceId with value empty / null / none at Tower it means use the user "personal workspace".

[jordeu]

Sounds great 👏🏻

Apologies again for my poor issue etiquette yesterday, should I make a new issue for this? The original topic in this issue is about creating a new TOWER_COMPUTE_ENV env var for the cli.

I've created an independent issue to allow empty envars. https://github.com/seqeralabs/tower-cli/issues/149

So here we can follow the discussion about TOWER_COMPUTE_ENV proposal.

[jordeu]

I've doubts about adding a new variable that can be contradictory with the TOWER_WORKSPACE_ID, I mean that you can have a compute env that is not part of the workspace.

Also we've plans to add some kind of configuration file (maybe .tower-cli.yml ?) where you'll be able to configure the default "profile" with all these settings. Maybe this will work for your use case?

I'll label this as "on hold" to re-evaluate it when we've this "profile" feature.