Configuration to work with GitHub Codespaces

[Ryszard-Trojnacki]

Description

Configuration for GitHub Codespaces to be able to work with LiteFarm source code with only installed Visual Studio Code or via web browser.

Jira link: N/A

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

We are working with this configuration for 2 months developing polish translation.

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The precommit and linting ran successfully
• I have added or updated language tags for text that's part of the UI
• I have added "MISSING" for all new language tags to languages I don't speak
• I have added the GNU General Public License to all new files

[Duncan-Brain]

Hello, wondering if you could provide any more context about this? Thanks!

[Ryszard-Trojnacki]

Of course. In our institute (Łukasiewicz Institute of Aviation) there are two reasons for which this helps a lot:

1. Because of IT security we are not allowed to install any software on our computers by our own. Everything has to be done by IT administrators and so not every software is allowed for installation (Docker is not allowed). This (GitHub Codespaces) allows us to work (develop) with LiteFarm because only Visual Studio Code is required to be installed and this can be done without administrative installation (local account installation).
2. Some of our workers that are working with LiteFarm are not software developers and running this locally is almost imposible for them. They don't know: node, docker etc. Working with LiteFarm with GitHub Codespaces just needs Visual Studio Code, few clicks (with Remote Explorer: Connect to Codespace/Create New Codespace) and two commands in terminal: nvm use && npm run dev.

Why this is needed?

• language translations are not done by software developers,
• testing application (translations, changes) are not done be software developers,
• checking if everything makes sense in application is not done be software developers.

With this PullRequest difficulty level for running/developing LiteFarm is much lower.

To work with LiteFarm with GitHub Codespaces you need only:

1. Download Visual Studio Code.
2. Install GitHub Codespaces extension.
3. In Remote Explorer select Create New Codespaces... select right repository, branch and device (basic is enough).
4. Wait about 6 minutes to start.
5. Setup .env files.
6. Run: nvm use && npm run dev and you are ready to develop/test.

[antsgar]

Thank you for the contribution, this is a really cool idea! I added a comment and a couple of questions

[antsgar]

This probably comes from your organization's specific setup, but we don't currently support pl locale -- could we remove references to this? Actually, I'm thinking it might be better to remove the extensions from this file altogether, since we don't currently have a unified criteria on extensions to use as a team and it's up to each developer to use the tools they deem necessary

[Ryszard-Trojnacki]

Yes and no. We were working on polish translation to LiteFarm and it is almost done: https://github.com/Lukasiewicz-Instytut-Lotnictwa/LiteFarm/tree/feature/GL-4-polish-translation.
Expect a pull request soon. But of course this is not important. It just helps to find spelling errors in translation files when working with Visual Studio Code.

[antsgar]

Could you please explain what this block should be doing? It seems it does the same in both cases of the condition

[Ryszard-Trojnacki]

In my computer (Debian Bookworm) there is command docker-compose and when I try to run docker compose (without -) then I have an error:

$ docker compose
docker: 'compose' is not a docker command.

On the other hand in GitHub Codespaces there is command docker compose.

Command docker-compose is the old docker script command and as I know it is not maintained anymore but exists on some systems (like mine Debian).
Command docker compose is the new docker script and should be use.

In summary this is only for backward compatibility.

I use this script to start development on my local computer (it works not only in GitHub Codespaces).
Of course it can be removed in favour of the new version docker compose.

(I'm not sure why Debian Bookworm has such old version of Docker - 20.10 vs current 27.)

[antsgar]

Is this redundant since it's in the post-create script?

[Ryszard-Trojnacki]

At first I had this only in post-start.sh because it is needed to start docker each time the machine starts, but I forgotten that I need to start once npm run migrate:dev:db. Without this script application isn't working correctly.

Script post-create.sh is executed only once, when the machine is created and it the right place to execute npm run migrate:dev:db, but to run this the database needs to be started and so docker compose up --detach is required.
Maybe it would be better to call sh ./post-start.sh instead of this if.

I'm not sure, if there should be another check if docker isn't running. Because on the first time post-create.sh is executed and then post-start.sh (two scripts, one after other). And then (everyother start of the machine) only post-start.sh. But at the first time (when machine is created) docker compose up is called two times. Not sure if this ends with error which of course can be ignored but is not nice. Let me check this...

[Ryszard-Trojnacki]

Running multiple times docker compose up doesn't throws any errors it just displays that everything is running, then it is better to leave it this way, without checking it in the shell script.

In summary this block in post-create.sh script can be replaced with call to sh ./post-start.sh script, but I'm not sure what is the working directory, then it would be better to call it this way:

# Get script directory
DIR="$(cd "$(dirname "$0")" && pwd)"

# Start Docker before running: npm run migrate:dev:db
sh "$DIR/post-start.sh"

The DIR variable can be set at the start of post-create.sh script, because it could be used in fututre in other places (?).

[Duncan-Brain]

Thanks for the extra context about it being for translations!

I think we are excited to host more languages in the future and it sounds like someone from your team has been in touch with our farmer success manager @dtrapplitefarm so that is great since we are working on a new process for internationalization.

If you are looking for other tools to help do translations with farmers, we have had another contribution that uses a chrome extension to do translations in context and generate the json files as well -- but it might be a little bit behind on our integration branch: #3227

We have not been able to integrate it yet... but the author demo-ed it to me and it seemed very useful too if you were interested in testing it out!

[Ryszard-Trojnacki]

it sounds like someone from your team has been in touch with our farmer success manager @dtrapplitefarm

Yes, that's me.

[antsgar]

@Ryszard-Trojnacki just an update since it's been a few days -- unfortunately we don't have much bandwidth to re-review this in depth at the moment, so it honestly might be a while before we get to it.

On the other hand, as @Duncan-Brain mentioned, we have a new process for incorporating new languages to the app, and we also want to be mindful and carefully evaluate and plan for opportunities for adding new translations since each new language we decide to support requires effort and time from the core team. With this in mind, please kindly reach out and discuss with David, our Farmer Success Manager (I see that Duncan mentions that you're already in touch, so that's great) before opening a PR for a Polish translation. Thank you!