Replies: 2 comments
-
Favorite ideas so far:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Closed in favor of already existing #968 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
[Moved to https://github.com//discussions/968]
This is a collection of unordered thoughts I had trying to figure out this conundrum. We're now adding file parsing and file generating executables to the very start of the test run, before setting up servers or anything else. This puts us in a bit of a bind as to where to store the artifacts folder name so that the local env still won't worry about creating the name in bash and so that, at the same time, ALKilnInThePlayground interviews can still access the name, ideally without a breaking change. (ALKilnInThePlayground has a problem right now for multiple users and
runtime_config.json
anyway.)local dev
setup (runtime_config value exists, env var doesn't)
validate (usually: runtime_config value exists, env var doesn't)
generate (both can exist)
run cucumber (both can exist)
takedown (both can exist)
DON'T WANT TO USE RUNTIME_CONFIG.JS
playground
middle 3 same as dev flow
NEEDS RUNTIME_CONFIG TO GET THE RESULTS FILES TO THE INTERVIEW AFTERWARDS
GitHub
server setup (not included)
setup (env var exists)
validate (both can exist)
same for the rest
Pretty flexible about the whole thing
So what to do?
If use runtime_config, local tests will always save to the same folder. Bad
If use env var, Playground won't be able to show user the results. Bad
Maybe we need to be annoying to the local dev environment and generate the value externally there too, just like in GitHub
And/or in Playground generate the artifact folder name in the interview.
What's better? Always generate and pass it externally and from then on always use the runtime config? (local setup and takedown would always be separate, but heck, that's not so important in the long run. and if it is we can figure out what to do, though it'll be ugly.)
2 (3, 4?)
Have both the config value and the env var and have a flag to tell local development to use only the env var?
3
Always clear out the config value when we're done with the test run with an additional final cleanup_config.js
(which adds to run_cucumber? no)How to run that in our package.json while still passing command line args tonpm run cucumber
? That might mess up ALKilnInThePlayground tests if multiple people are using them. Though that'll get messed up anyway since there's only one global variable.If we set the value in the interview instead of doing it in the script and saving it in runtime_config.js then ALKilnInThePlayground won't need to use runtime_config. Gorrammit.
Ok. How do we make a script that everything can use externally to set the artifacts folder name env var or something?
Or really maybe just clear the config value at the end of the test suite run. Bleh. Why not? I'm not sure. I'm worried about it.
Use 2 background processes. 1st to set the value in runtime config. Save it in the interview. Pass it on to the next process that does the rest. Yes? That seems better than waiting for all the tests to run.
Find a dir to put a file in a Playground Project, or associated with a Playground Project, where it won’t get added to the repo when someone commits and pushes to GitHub [which is apparently anywhere in the project's folder? Try adding to the source's folder? Or grep for the name of the Project and also look for the id of the user]. Alternatively, save using a timestamp. Make runtime config values in a list on the server. Pass that value into a script that... I'm not sure. Maybe we really do use it to make the artifacts folder (if it's there). Maybe associate it with the artifacts folder somehow. Later, use it to get the config.
Alternatively, in the runtime config (only on the server?) add the Project name to the artifacts folder name (in a list of file names) and always use the latest config value [timestamp?] for that project to get the runtime config value. Alternatively, use the Project Name as a key for a value in the config and save each artifact folder name in there. Conditional on the key's existence (with the old method as the fallback), use the last item in the list to get the artifacts folder name.
Also, maybe [in the Playground or everywhere?] change the name to alkiln_runtime_config.json.
Tangentially, we're creating the runtime_config much earlier, so it's more likely to exist.
https://kodekloud.com/blog/return-value-from-bash-function/#2-methods-to-return-value-from-a-bash-function. With that, it's quite possible we could send out the artifacts folder name pretty early on. Do we still have to save it somewhere or will the interview variables keep it? I think the latter.
Also, we should add it to the report header along with the ALKiln version number.
Beta Was this translation helpful? Give feedback.
All reactions