Configure github's codespaces

[TotoGaz]

This PRs configures the repository to be able to use https://github.com/features/codespaces . It's possible to get a configured env up and running in the cloud in a matter of minutes.

I think this can answer some kinds of specific needs (intern working on non strong HPC subjects can start in a few minutes, partners can intervene for spot actions like bug fixes...)

One issue is that it does imposes the duplication of the GEOSX_TPL_TAG. There may be ways to extract this the .travis.yaml file. To be investigated.

Also, something needs to be done for the .vscode folder which is shared by many. Being in .gitignore, it should be OK I think.

Related to https://github.com/GEOSX/thirdPartyLibs/pull/203

[rrsettgast]

@TotoGaz Should I be able to test at his point?

[TotoGaz]

@TotoGaz Should I be able to test at his point?

Given that your github organization allows codespaces and that you can switch to this PR's source code, then yes, it should be up and running. I can make a demo to whoever's interested.

[TotoGaz]

Looks great !!

Thx 😉

How will you orchestrate paraview with all that (as you added deps in Dockerfile for it) ?

I don't know yet, it's still something I should be working on. But I did not really have the time.

Are you planning on some quick-start doc page on it in a separate PR or should it be in this one ?

Yes, but I'd like to coordinate with the vs-code doc as well.

[rrsettgast]

@TotoGaz It appears that using code spaces costs money? Am I missing something? https://docs.github.com/en/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces

[TotoGaz]

@TotoGaz It appears that using code spaces costs money?

Yes it does since you are buying resources in the cloud.

In our case, we may want to involve people for a very limited amount of time (engineers to help us fixing bugs here and there). For this kind of use case, having a GEOSX env set up in minutes is very useful and will save us a significant amount of time (and money 🤷 ). For people investing on the long term on GEOSX for HPC, it's surely not very useful (except that you can get used to a working GEOSX and it's build system first before setting up your own env, which can be nice). For non HPC related interns, they can start working in 10 minutes, not having to wait for accounts, permissions, etc.

So it's not the absolute solution, but more another string to our bow. Like the auto deployment for us: surely not the best (in the absolute), we're aware of it, but a great tool nevertheless.

And finally, nobody can never say it's so complicated to start developing in GEOSX: in 3 minutes you are building GEOSX in a validated env.

[TotoGaz]

@rrsettgast @CusiniM I've used a link which is built on the fly from .vscode-codespaces to .vscode. So I think that the situation is nice now (w.r.t. conflicts with others' settings). The TPL tag in the .devcontainer/Dockerfile is set to DEFINE_ME (I've added a comment on what to do).

[CusiniM]

@rrsettgast @CusiniM I've used a link which is built on the fly from .vscode-codespaces to .vscode. So I think that the situation is nice now (w.r.t. conflicts with others' settings). The TPL tag in the .devcontainer/Dockerfile is set to DEFINE_ME (I've added a comment on what to do).

Nice!

[TotoGaz]

@rrsettgast @CusiniM is it possible to merge this PR as is? It think there's no more conflict, and it can be used as an example on how to use vscode as well.