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

remove python dependency to simplify use in MFE build/deployment #4

Closed
brian-smith-tcril opened this issue Nov 16, 2022 · 5 comments · Fixed by #5
Closed

remove python dependency to simplify use in MFE build/deployment #4

brian-smith-tcril opened this issue Nov 16, 2022 · 5 comments · Fixed by #5

Comments

@brian-smith-tcril
Copy link
Contributor

Considering the goals of https://github.com/openedx/openedx-translations include no longer having translated strings checked in to individual repos, it makes sense to utilize atlas during the build/deployment process for MFEs. With this in mind, as discussed in OEP-58

Having atlas built in python adds complexity to the deployment of MFEs.

A few options were presented:

After looking into these options, moving to bash seems to be the simplest way to ensure the functionality we desire from atlas is available in all the environments we expect to run it in.

@brian-smith-tcril
Copy link
Contributor Author

one thing to consider with a move to bash is testing

i think a good path forward for that would be to utilize bats and bats-mock

@brian-smith-tcril
Copy link
Contributor Author

brian-smith-tcril commented Nov 17, 2022

another thing to consider is argument parsing, it seems https://argbash.dev/ should be a good way to handle that

example argbash template for parsing atlas args

#!/bin/bash
#
# openedx-atlas argbash (https://argbash.dev/) argument template
#
# ARG_OPTIONAL_SINGLE([config], , [path to alternative atlas.yaml configuration file])
# ARG_OPTIONAL_SINGLE([branch], b, [branch to pull], [main])
# ARG_OPTIONAL_SINGLE([repository], r, [repository to pull])
# ARG_OPTIONAL_SINGLE([directory], d, [directory to pull])
# ARG_POSITIONAL_SINGLE([positional-command-arg], [only one command is available: pull], )
# ARG_HELP([Atlas is a CLI tool that has essentially one command: \`atlas pull\`\n \nAtlas defaults to using a configuration file named `atlas.yaml` placed\nin the root directory. Configuration file:\n \npull:\n  branch: <branch-name>\n  directory <directory-name>\n  repository: <organization-name>/<repository-name>\n \nAtlas can also use a configuration file in a different path using the \`--config\` flag\nafter \`atlas\`: \`atlas --config pull\`.\n \nAtlas can also be used without a configuration file by using the flags below after\n\`atlas pull\`.\n \n\`-b\` or \`--branch\`\n\`-r\` or \`--repository\`\n\`-d\` or \`--directory\`\n])
# ARGBASH_GO

# [ <-- needed because of Argbash

echo "Value of --config: $_arg_config"
echo "Value of --branch: $_arg_branch"
echo "Value of --repository: $_arg_repository"
echo "Value of --directory: $_arg_directory"
echo "Value of positional-command-arg: $_arg_positional_command_arg"

# ] <-- needed because of Argbash

@brian-smith-tcril
Copy link
Contributor Author

recommendation from @kdmccormick https://www.shellcheck.net/wiki/Home

ShellCheck is a static analysis tool for shell scripts. This wiki holds all the long form descriptions of warnings and suggestions it outputs. If you get this output:

@brian-smith-tcril
Copy link
Contributor Author

brian-smith-tcril commented Nov 28, 2022

i put together a proof-of-concept of this

the atlas side is here: brian-smith-tcril#1, it includes a gh actions workflow that runs argbash and shellcheck, as well as a workflow that runs when a tag is pushed to create a release

on the MFE side of things, i put together a proof-of-concept on this branch of course authoring. this branch updates the pull_translations target in the makefile to download and run a specified release of atlas

things left to do for feature parity with the python version:

  • automated testing

@brian-smith-tcril
Copy link
Contributor Author

after looking over a bunch of different testing frameworks, i've decided to move forward using ShellSpec

my reasoning behind this decision:

(potential/subjective) downsides to this choice:

  • i'm not the biggest fan of the BDD DSL
  • it's only 3 years old

alternatives considered (why i decided against them):

  • Bats (very bash focused)
  • shUnit2 (not well maintained, missing a few QoL features)
  • bash_unit (very bash focused)
  • shpec (seems like a less feature-complete version of ShellSpec)

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

Successfully merging a pull request may close this issue.

1 participant