Architecture: Where should we create/save the artifacts folder path?

[plocket]

Right now it's in Log.js, but I'm not a fan. It feels hidden away in an obscure place. I'm not sure where to put it, though.

It could be in files.js (files.make_artifacts_folder()). I believe we were keeping session_vars out of there for some reason, but I don't remember what that reason was. session_vars isn't using files. Maybe just to keep it as simple as possible. Still, it may be worth changing that to get this functionality in a sensical place. We could put the whole path creation flow in there.

[Maybe tangential: For the sandbox GitHub server action, when we integrate Log.js into the GitHub server stuff, we'll need to think about where we create the env var because the GitHub action happens completely separately and the env var won't carry over to the ALKiln action. Probably use an output. Otherwise, I think we shouldn't manage the env var in the actions to keep the implementation of saving artifacts paths contained in case it changes in the future.]

Thoughts?

[plocket]

From #969

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 to npm 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.

[plocket]

From #969

Favorite ideas so far:

• Clear the name from the config after finishing a test suite run. Make a new name at the start.
• ALKilnInThePlayground: Store the runtime_config.json in a Project folder. No list, just the latest value. Explore the file system to see where to keep it. Folder in the 'sources' folder maybe.
• stdout the name of the artifacts folder so that ALKilnInThePlayground can get it.