App-version specific environment variable

Hi,
Can someone confirm that monday-code Environment variables are shared across all versions of the installed app? That’s seems to be the supported behavior, as no versionId can be used in mapps code:env CLI

If that’s the case (and that’s what I see – I have a live version and a draft, whenever I set one env var it changes the other one as well, unfortunately) - what’s the strategy for testing scenario which I assumed to be controlled by an env var value?

1 Like

Have a separate monday.com instance where you do all your testing first, before updating on your production system.

  1. I’m on a developer monday.com account, do you know if that’s possible in that case?
  2. I was also thinking about duplicating apps, under a single instance. Is that something that can easily done? I guess the burden is on all the work is being done on the developers center->app->features. If that part can be easily duplicated (e.g. by CLI command of some kind), that would be awesome.
  3. Assuming I want to have the logic of version id retrieval on my app, at least at the time being, I was hoping I could get it done in python, I saw a previous post of yours which directing to monday.get sdk - is it possible in python somehow??

@eyalos None of this is easily duplicated.

You have to spend the time with 2 browser windows open copying text from one into the other, praying that you haven’t introduced any mistakes.

Vote this up to remove some of the pain:
Apps should have an app descriptor file that defines what the app does (app manifest)

I’d have the duplicate app on a different instance, so the app is isolated elsewhere.

@dvdsmpsn thanks, voted up for your request.
Any comment on the 3rd Q, that’s how to use monday.get (or alternative) in python?

No idea in python. Sorry.

monday.get() is a front end UI capability only. Its only relevant in UI features - which since they run in the browser are going to be JavaScript only.

On the backend you only have the API itself, and what is provided by the Python SDK.

On the backend the expectation is you change your URLs for draft testing. End users are always going to be on your live version. So when testing your drafts you just have a separate instance and you change the URL being used to point to that.

The version ID stuff was more important in the past when there was the “major/minor” versioning where major versions would freeze and orphan old versions. They got rid of that so everything now stays up to day.

Thanks @codyfrisch !

I guess there’s no way around a dedicated-testing-environment for sandbox-testing my app.
I firsts thought draft version (in contrast to the live one) is a way of doing environment specific testing, but I now see that’s not the case.

@Matias.Monday Can you help with my options as a developer to have multiple accounts?
That’s related to @dvdsmpsn’s suggestion:

Thanks all for your time and sharing your knowledge!

Hello again @eyalos,

Would you be able to please fill this form explaining the use case and why you need new testing accounts so that our team can evaluate it?

Looking forward to hearing from you!

Cheers,
Matias

1 Like