Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add minimal atlas step to the build FC-0012 #41

Merged
merged 1 commit into from
Oct 16, 2023

Conversation

OmarIthawi
Copy link
Contributor

@OmarIthawi OmarIthawi commented Aug 2, 2023

Add https://github.com/openedx/openedx-atlas to the Dockerfile and run the atlas pull command on every build.

I'm starting here because this is a simple plugin and helps us to design it properly. The end goal is to add atlas on all other components including edX Platform, MFEs and possibly even ecommerce.

This is a very minimal build that needs the following to be viable:

  • Ability to configure the repo, branch and other options.
  • Possibly make it a system-wide pattern in tutor instead of adding it to individual components.

This PR requires the following branch of discovery: openedx/course-discovery#4037

TODO

Building and testing logs
# Set the following variables:
# DISCOVERY_ATLAS_ARGS: --filter=ar,de
# DISCOVERY_ATLAS_PULL: true

$ tutor config save
$ tutor images build discovery
Building image docker.io/overhangio/openedx-discovery:16.0.0
....
$ docker run -it docker.io/overhangio/openedx-discovery:16.0.0 atlas --version
v0.4.4

Check the file tree

$ docker run -it docker.io/overhangio/openedx-discovery:16.0.0 ls -R course_discovery/conf/locale/
course_discovery/conf/locale/:
ar  config.yaml  de

course_discovery/conf/locale/ar:
LC_MESSAGES

course_discovery/conf/locale/ar/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/de:
LC_MESSAGES

course_discovery/conf/locale/de/LC_MESSAGES:
djangojs.po  django.po

Verify translations within the image:

$ docker run -it docker.io/overhangio/openedx-discovery:16.0.0 cat course_discovery/conf/locale/de/LC_MESSAGES/django.po | head -n 100
# #-#-#-#-#  django.po (course-discovery)  #-#-#-#-#
# edX translation file
# Copyright (C) 2018 edX
# This file is distributed under the GNU AFFERO GENERAL PUBLIC LICENSE.
# 
# Translators:
# Translators:
# Omar Al-Ithawi <[email protected]>, 2023
# 
msgid ""
msgstr ""
"Project-Id-Version: edx-platform\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2023-08-03 00:22+0000\n"
"PO-Revision-Date: 2023-01-26 15:39+0000\n"
"Last-Translator: Omar Al-Ithawi <[email protected]>, 2023\n"
"Language-Team: German (https://app.transifex.com/open-edx/teams/147691/de/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: de\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#: apps/api/filters.py:47
#, python-brace-format
msgid "No user with the username [{username}] exists."
msgstr "Ein Nutzer mit Namen [{username}] existiert nicht."

#: apps/api/filters.py:50
msgid ""
"Only staff users are permitted to filter by username. Remove the username "
"parameter."
msgstr ""
"Nur Mitarbeiter sind berechtigt nach Benutzernamen zu filtern. Entfernen Sie"
" den Benutzername Parameter"

#: apps/api/serializers.py:813
msgid "Number of courses contained in this catalog"
msgstr "Anzahl der Kurse in diesem Katalog"

#: apps/api/serializers.py:816
msgid "Usernames of users with explicit access to view this catalog"
msgstr ""
"Benutzernamen der Nutzer mit ausdrücklichem Zugriff um diesen Katalog zu "
"sehen"

#: apps/api/serializers.py:976
msgid "Start date cannot be after the End date"
msgstr "Startdatum kann nicht nach dem Enddatum gesetzt werden"

#: apps/api/serializers.py:981
msgid "Term cannot be changed"
msgstr "Begriff kann nicht geändert werden"

#: apps/api/serializers.py:993
msgid "Language in which the course is administered"
msgstr "Sprache in der dieser Kurs verwaltet wird"

.....

Background

This contribution is part of the FC-0012 project which is sparked by the Translation Infrastructure update OEP-58.

Copy link
Contributor

@regisb regisb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like your approach of testing Palm on a smaller Tutor plugin. And I am also looking forward to ditching my very custom solution based on openedx-i18n. Let's try to get Atlas working on this repo before we attempt to tackle the openedx Dockerfile.

I'm curious, did you manage to build the discovery image with this PR? If yes, did you run your own fork of course-discovery? I did not test your changes but I suspect that I would not be able to build the Docker image without transifex credentials.

tutordiscovery/plugin.py Outdated Show resolved Hide resolved
# Collect static assets
# Update i18n and collect static assets
{% if DISCOVERY_ATLAS_PULL %}
RUN make OPENEDX_ATLAS_PULL=yes ATLAS_PULL_LANGS="{{ DISCOVERY_ATLAS_PULL_LANGS }}" pull_translations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • The DISCOVERY_ATLAS_PULL_LANGS setting is undefined. How can we make Atlas automatically (or at least: by default) download strings from all "sufficiently translated" languages? As a rule of thumb, we like to include in Tutor all languages with >50% reviewed strings.
  • In Palm, the make pull_translations command is going to run tx, and not atlas. Actually, neither does the master branch run Atlas.
  • Also, how are we going to pull translations from Transifex (I assume?) if there is no transifexrc file in the Docker image?
  • Actually, do we really have to run a make command? Can we just run atlas directly to remove one level of indirection?
  • Once we have a basic version working, we should try to move the atlas step to a separate Docker layer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DISCOVERY_ATLAS_PULL_LANGS setting is undefined. How can we make Atlas automatically (or at least: by default) download strings from all "sufficiently translated" languages? As a rule of thumb, we like to include in Tutor all languages with >50% reviewed strings.

True. I'll fix this.

In Palm, the make pull_translations command is going to run tx, and not atlas. Actually, neither does the master branch run Atlas.

This is work in progress and we're adding it to tutor at the moment. We will not merge unless everything is ready.

Also, how are we going to pull translations from Transifex (I assume?) if there is no transifexrc file in the Docker image?

Transifex won't be used directly anymore in Open edX. At least this is the direction we're going to according to OEP-58.

Actually, do we really have to run a make command? Can we just run atlas directly to remove one level of indirection?

No really. Except for MFEs, in which the make command is needed since it depends on the context: https://github.com/openedx/frontend-app-learner-dashboard/blob/master/Makefile#L63-L71

Once we have a basic version working, we should try to move the atlas step to a separate Docker layer.

I'd like to learn more what do you mean by this @regisb?

Thanks for the notes, obviously this is an experiment so your feedback is very helpful!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to learn more what do you mean by this @regisb?

It's a bit difficult to explain in writing. It has to do with not repeating the translation pull step unless necessary. The goal being to make it as fast as possible to re-build Docker images. It's OK, we can figure this out later.

@regisb regisb marked this pull request as draft August 3, 2023 08:38
@regisb
Copy link
Contributor

regisb commented Aug 3, 2023

I converted this PR to a draft, let me know when it's ready for another round of review.

@OmarIthawi
Copy link
Contributor Author

@regisb I've addressed some of your notes.

I think we still need some way to pass options for example:

Another feature is that atlas pull should be disabled by default, because at the moment it pulls an incomplete translation and it's worse than what's checkout on GitHub.

Atlas and Open edX Translations

Perhaps, it's good to share a recap on what happened on Atlas. Part of OEP-58, we've created two new additions to the Open edX Platform https://github.com/openedx/openedx-translations and https://github.com/openedx/openedx-atlas .

atlas pull replaces tx pull in which that it doesn't pull from Transifex, but pulls from the https://github.com/openedx/openedx-translations GitHub repo which makes it possible to pull without needing authentication or .transifexrc file.

Testing

$ tutor images build discovery
$ tutor dev run discovery -- atlas --help  # Prints the help message

File tree

The file tree seems about right. It removed the old files and add fresh ones from the repository (as opposed to Transifex).

$ tutor dev run discovery -- ls -R course_discovery/conf/locale
course_discovery/conf/locale:
ar  config.yaml  de  en  fr_CA

tutor dev run discovery -- ls -R course_discovery/conf/locale
course_discovery/conf/locale/ar:
LC_MESSAGES

course_discovery/conf/locale/ar/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/de:
LC_MESSAGES

course_discovery/conf/locale/de/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/en:
LC_MESSAGES

course_discovery/conf/locale/en/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/fr_CA:
LC_MESSAGES

course_discovery/conf/locale/fr_CA/LC_MESSAGES:
djangojs.po  django.po

@brian-smith-tcril
Copy link

I think we should wait until we implement openedx/openedx-atlas#34 and use pip

@OmarIthawi
Copy link
Contributor Author

@regisb and @brian-smith-tcril would you mind taking a look at this PR? It should be ready again for review.

tutordiscovery/plugin.py Outdated Show resolved Hide resolved
@OmarIthawi
Copy link
Contributor Author

@regisb I've updated the PR except for the args part which I tend to think it's valuable but I'd like to hear from you.

Anyway, it's not a blocker for this PR so we can remove it until we figure out another alternative.

axim $ tutor config save
Configuration saved to /home/omar/work/axim/config.yml
Environment generated in /home/omar/work/axim/env


axim $ tutor images build discovery
Building image docker.io/overhangio/openedx-discovery:16.0.0
....
 => => naming to docker.io/overhangio/openedx-discovery:16.0.0


axim $ tutor dev run discovery bash

app@c91d22d98665:~/discovery$ ls -R course_discovery/conf/locale/
course_discovery/conf/locale/:
ar  config.yaml  de  en  fr_CA

course_discovery/conf/locale/ar:
LC_MESSAGES

course_discovery/conf/locale/ar/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/de:
LC_MESSAGES

course_discovery/conf/locale/de/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/en:
LC_MESSAGES

course_discovery/conf/locale/en/LC_MESSAGES:
djangojs.po  django.po

course_discovery/conf/locale/fr_CA:
LC_MESSAGES

course_discovery/conf/locale/fr_CA/LC_MESSAGES:
djangojs.po  django.po

@OmarIthawi OmarIthawi requested a review from regisb August 17, 2023 09:19
@OmarIthawi OmarIthawi marked this pull request as draft August 17, 2023 10:11
@OmarIthawi
Copy link
Contributor Author

@regisb what do you think should happen if a po file fails to compile due to Translator writing invalid strings Hi {user} --> Merhaba {kullanci}?

Currently the docker build fails, which I think isn't appropriate.

I'm thinking we should add validation to the https://github.com/openedx/openedx-translations so this won't happen inside Tutor, correct?

cc: @brian-smith-tcril

@brian-smith-tcril
Copy link

@OmarIthawi I made an issue on the openedx-translations repo for validation openedx/openedx-translations#549

@OmarIthawi
Copy link
Contributor Author

Thanks Brian and Regis. I'll fix the openedx-translations repo first then I'll continue with this PR.

@OmarIthawi
Copy link
Contributor Author

@regisb @brian-smith-tcril would mind taking another look?

This took a lot of experimentation and review effort, but I hope it's worth it. I've also made sure that atlas pull gets valid pofiles by validating pofiles at the source repo:

@regisb regisb self-assigned this Aug 28, 2023
Copy link
Contributor

@regisb regisb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to my comment, can you please add a changelog entry with scriv create?

openedx-atlas==0.4.4

# Update i18n: the equivalent of "make pull_translations"
RUN find course_discovery/conf/locale -type d -mindepth 1 -maxdepth 1 -exec rm -rf {} + # Remove stale translation files
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes all translation files currently in course_discovery/conf/locale to be deleted. Not all translation files will be replaced by atlas pull. This means that some languages will no longer be available to existing users, which is not acceptable.

Is there an alternate solution? Can we just skip the deletion step?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes all translation files currently in course_discovery/conf/locale to be deleted. Not all translation files will be replaced by atlas pull. This means that some languages will no longer be available to existing users, which is not acceptable.

This ideally shouldn't be a concern as long as both projects translations have the same completeness. Which is still work in progress.

Once OEP-58 is fully implemented, repos will have no translations committed. Again, removing the deletion step is future-proof, so it should be fine.

Is there an alternate solution? Can we just skip the deletion step?

I'll see if skipping the deletion step works.

I'll have to share few minor concerns that this PR should balance:

  • What if some translations are broken in the original repo? Then atlas pull won't fix those errors. What do you think?

  • In MFEs, it's preferable to have only the used languages to reduce the JavaScript bundle because translations are compiled and bundled into the code. But this isn't an MFE.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ideally shouldn't be a concern as long as both projects translations have the same completeness. Which is still work in progress.

OK. So this PR is not 100% ready to be merged, right?

What if some translations are broken in the original repo? Then atlas pull won't fix those errors. What do you think?

I'm fine with existing bugs, I just don't want to create new ones. It's not atlas' job to fix existing translations issues.

In MFEs, it's preferable to have only the used languages to reduce the JavaScript bundle because translations are compiled and bundled into the code. But this isn't an MFE.

That's a good point. But then again, it's not like MFE bundles are suddenly going to get very big. They already contain all the translation strings, right? Plus, it seems to me that translations strings take little size compared to vendor libraries.

Copy link
Contributor Author

@OmarIthawi OmarIthawi Sep 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. So this PR is not 100% ready to be merged, right?

Yes, I somewhat missed this big issue. My bad for removing the flag which I orgininally added in thi

We want to ship it behind a feature flag like all the other repos, then we'll flip the switch once the Transifex project is fully migrated.

I need to get back the "OPENEDX_ATLAS_PULL" flag which has been the standard in all repositories such as:

That's a good point. But then again, it's not like MFE bundles are suddenly going to get very big. They already contain all the translation strings, right? Plus, it seems to me that translations strings take little size compared to vendor libraries.

Correct. This is still an open discussion in the Transifex Working Group. But yeah, it shouldn't be a concern in this context.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(sorry about the review delay)

Honestly I'm not a big fan of the feature flag. Managing feature flags across multiple repositories is a pain which I'd rather avoid. Either the feature is ready for launch, in which case we don't need the feature flag in Tutor, or it is not, and in that case atlas pull should be implemented with a plugin. (Yes, that would be a plugin for a plugin...)

If the latter, then all your changes can be added to the discovery Dockerfile with a single extra {{ patch("discovery-dockerfile") }} statement (we would just have to think about that patch name and add it to this repo).

This comment was marked as duplicate.

Copy link
Contributor Author

@OmarIthawi OmarIthawi Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@regisb I just saw your comment 😿

It's ready'ish, so no it's not ready.

It'll only be considered ready once someone else approves it to be and uses it on their stacks. So it's puts us in a chicken-and-egg issue.

I'll check with the team on the plugin decision and get back to you. It seems to be a good solution, except for the timeline potential delays.
I'll be somewhat a pivot which needs more exploration (and more Tutor learning for sure) from my side.

@brian-smith-tcril from timeline perspective, what do you think about creating a plugin for atlas on discovery, or for Tutor in general?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm eager to see Atlas succeed and don't want to cause extra delays. If it's a chicken and egg thing, and building a plugin would further delay the project, then we can help resolve the situation by hiding the feature behind an undocumented feature flag in the tutor-discovery plugin, just like you suggested. We should make it clear that it's a temporary, unsupported feature flag, and the flag should not be present in other core plugins.

Thus I no longer have any objection to your PR and I'd say I'm ready to merge it when you are.

Copy link
Contributor Author

@OmarIthawi OmarIthawi Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, making it a plugin isn't a bad choice, in fact it's pretty good one. However, it's bit more costly than direct pull requests, so I'd like to hear from @brian-smith-tcril.

I imagine if we have an tutor-atlas plugin which adds Tutor patches to all other plugins would be a nice way to make atlas optional.

the feature behind an undocumented feature flag in the tutor-discovery plugin, just like you suggested

Great, thanks for being open for the lesser option for the sake of timeline. Today, we'll know which way to go.

Options to implement Atlas

Option 1: enable always

  • Perfect the translations workflow

    • Sync all languages to the repo
    • Ensure no invalid translations being committed to the repository
  • Enable atlas by default without a feature flag on Tutor nightly core and plugins

This option makes it very slow to get feedback and risks the timeline push.

Option 2: temporary feature flag first

  • Enable atlas behind an undocumented temp. feature flag on Tutor nightly core and plugins
  • Perfect the translations worflow in parallel
  • Enable atlas by default without a feature flag (Same as Option 1)

With this option, others can use atlas faster.

Option 3: plugin first

  • Create an tutor-atlas plugin to use atlas on Tutor core and other plugins
  • Perfect the translations worflow in parallel
  • Once completed, tutor-atlas will be moved to core (Same as Option 1)

This option makes it is faster than Option 1 in terms of feedback, but also slower than Option 2 and could impact the timeline negatively.

@regisb regisb assigned OmarIthawi and unassigned regisb Sep 5, 2023
@OmarIthawi
Copy link
Contributor Author

@regisb the pull request is ready again for review.

@OmarIthawi OmarIthawi changed the title [WIP] feat: add minimal atlas step to the build feat: add minimal atlas step to the build Sep 9, 2023
@OmarIthawi
Copy link
Contributor Author

@regisb a gentile reminder about this pull request :)

@regisb
Copy link
Contributor

regisb commented Sep 19, 2023

pulling in @Faraz32123 who is the new maintainer for this plugin.

@OmarIthawi
Copy link
Contributor Author

@Faraz32123 would you mind checking this pull request?

@regisb
Copy link
Contributor

regisb commented Oct 2, 2023

@OmarIthawi did you see my last comment above?

@OmarIthawi
Copy link
Contributor Author

OmarIthawi commented Oct 5, 2023

@regisb Let's please continue with the feature flag the three of us thinks it's the way to go.

I don't fully understand Tutor branching strategy, so should I change the base branch from master --> nightly?

@regisb
Copy link
Contributor

regisb commented Oct 5, 2023

I don't fully understand Tutor branching strategy, so should I change the base branch from master --> nightly?

Do you want the feature in the Palm release? If yes, then keep the base branch as master, and it will also be included in nightly. If the feature should only target the upstream master branch of the course-discovery repo, aim for the nightly branch here. For more information: https://docs.tutor.overhang.io/tutorials/nightly.html

@OmarIthawi
Copy link
Contributor Author

@regisb for the discovery, I think it should go to nightly so it's included in Quince.

All other atlas pull requests should go to nightly except for the MFE because the communications MFE needs atlas in Palm.

@regisb
Copy link
Contributor

regisb commented Oct 9, 2023

@regisb for the discovery, I think it should go to nightly so it's included in Quince.

To be clear: if atlas goes to the plugin master branch, the change will also be included in Quince. We should push to nightly only if the change does not work in Palm.

Does that make sense?

@OmarIthawi
Copy link
Contributor Author

OmarIthawi commented Oct 9, 2023

@regisb for the discovery, I think it should go to nightly so it's included in Quince.

To be clear: if atlas goes to the plugin master branch, the change will also be included in Quince. We should push to nightly only if the change does not work in Palm.

Does that make sense?

Yes, makes sense :)

I don't want tutor-discovey to support atlas in Palm. Therefore it'll go to nightly so it's only Quince and beyond.

@OmarIthawi OmarIthawi changed the base branch from master to nightly October 9, 2023 08:38
@OmarIthawi
Copy link
Contributor Author

OmarIthawi commented Oct 10, 2023

@regisb @Faraz32123 I've rebased over nightly and tested the build and it pulled the translations correctly:

Sample output from the build logs
$ pip install -e tutor-discovery
$ tutor config save && tutor images build discovery

...
 => [minimal 16/19] RUN atlas pull  translations/course-discovery/course_discovery/conf/locale:course_discovery/conf/locale                           2.0s 
...

app@e4c97e0af60c:~/discovery/course_discovery/conf/locale$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   ar/LC_MESSAGES/django.mo
	modified:   ar/LC_MESSAGES/django.po
	modified:   ar/LC_MESSAGES/djangojs.mo
	modified:   ar/LC_MESSAGES/djangojs.po
	modified:   da/LC_MESSAGES/djangojs.mo
	modified:   da/LC_MESSAGES/djangojs.po
	modified:   de/LC_MESSAGES/django.mo
	modified:   de/LC_MESSAGES/django.po
	modified:   de/LC_MESSAGES/djangojs.mo
	modified:   de/LC_MESSAGES/djangojs.po
	modified:   de_DE/LC_MESSAGES/djangojs.mo
	modified:   de_DE/LC_MESSAGES/djangojs.po
	modified:   el/LC_MESSAGES/djangojs.mo
	modified:   el/LC_MESSAGES/djangojs.po
	modified:   en/LC_MESSAGES/django.po
	modified:   en/LC_MESSAGES/djangojs.po
	modified:   fr_CA/LC_MESSAGES/django.mo
	modified:   fr_CA/LC_MESSAGES/django.po
	modified:   fr_CA/LC_MESSAGES/djangojs.mo
	modified:   fr_CA/LC_MESSAGES/djangojs.po

$ git diff
+++ b/course_discovery/conf/locale/ar/LC_MESSAGES/django.po
@@ -5,34 +5,17 @@
 # 
 # Translators:
 # Translators:
-# 7a89e761fc15f91cc2a9e7bcff1a9c10, 2019
-# Ahmed Jazzar <[email protected]>, 2016
-# Amira 111111111111111111 <[email protected]>, 2016
-# 6e68c7971a89e50e680ae9444d303c8f, 2016-2017
-# AR R1 <[email protected]>, 2016
-# Dillon Dumesnil <[email protected]>, 2021
-# e2f_ar r3 <[email protected]>, 2016-2017
-# e2f_ar t3 <[email protected]>, 2016
-# Hamza Assada <[email protected]>, 2020
-# Hamza Madni, 2022
-# Natalia Berdnikov <[email protected]>, 2016
-# NELC Open edX Translation <[email protected]>, 2020
-# Omar Al-Ithawi <[email protected]>, 2016
-# qualityalltext <[email protected]>, 2016
-# Rama Alshebel, 2021
-# Renzo Lucioni <[email protected]>, 2017
-# Roaa Nader <[email protected]>, 2021
-# Sahbi BG <[email protected]>, 2017
-# SAM.AM <[email protected]>, 2019
-# shefaa abu jabel <[email protected]>, 2016-2017
+# Omar Al-Ithawi <[email protected]>, 2023
+# Brian Smith, 2023
+# 

I think this pull request is ready to be merged.

BTW, we've added translation validation, so if the the feature flag was removed, it would still be production ready, at least up to our knowledge.

@OmarIthawi OmarIthawi changed the title feat: add minimal atlas step to the build feat: add minimal atlas step to the build FC-0012 Oct 13, 2023
Copy link
Contributor

@regisb regisb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for bearing with me Omar!

@regisb regisb merged commit b9dd940 into overhangio:nightly Oct 16, 2023
@OmarIthawi
Copy link
Contributor Author

Hey!! That's a great way to end the day. Thanks @regisb!

Thanks for bearing with me Omar!

On the contrary! It's been a great review. I'm new to Tutor anyway, so I'm expecting a lot of comments anyway.

@@ -31,6 +31,7 @@
"OAUTH2_KEY_SSO": "discovery-sso",
"OAUTH2_KEY_SSO_DEV": "discovery-sso-dev",
"CACHE_REDIS_DB": "{{ OPENEDX_CACHE_REDIS_DB }}",
"ATLAS_PULL": False,
Copy link

@shadinaif shadinaif Nov 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@OmarIthawi , shouldn't this be DISCOVERY_ATLAS_PULL ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shadinaif the prefix is automatically added via Tutor. So in the config.yaml file it will be DISCOVERY_ATLAS_PULL: true.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

5 participants