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

♻️ 💅 Cleanup/polish the code to automatically cascade images from the server -> server dependencies #1082

Open
14 tasks
shankari opened this issue Aug 12, 2024 · 0 comments

Comments

@shankari
Copy link
Contributor

shankari commented Aug 12, 2024

Copied over pending tasks from:
e-mission/e-mission-server#961 (comment)

  • change all the images to be stored in the emission dockerhub instead of my personal dockerhub account
    • even better, store them in github ghcr.io so that we don't run into issues with usage limits
  • Explore whether we can stop uploading the date of of the run as an artifact since we are using an .env file in the dashboards. Can't this just be an output of the run?
  • Also we might want to just rebuild on releases (marked with a tag) instead of every push anyway.
  • and may also want to make the push conditional on the tests passing
  • Instead of having two separate files for the analysis config (which then have to be kept in sync), just edit the dev in prod mode to turn off the assertions
  • remove the secret auth method since it is unused
  • consider using a similar cascade from e-mission-common to the various repos
    • also, consider pulling out e-mission-core as a separate library that is similar to e-mission-common
    • we will only need to pull e-mission-core into the dashboard repos then; we don't need the full analysis pipeline
  • we currently have two copies of the cascading code (in the two dashboard repos). We should explore unifying them. Maybe nested workflows?
  • Consider switching from $GITHUB_ENV to step outputs. I think that the step outputs are the recommended approach to pass values from one step to another, but we should verify
  • Discuss where to put in the cert configuration. We originally had it in the internal repos, then we moved it to the external repos. But now that we have one internal dockerfile per external dockerfile, maybe we can have it be internal after all. It doesn't actually hurt anything to be external, but it is unnecessary in the external repo.
  • upload/store the correct tag. Right now the tag in dockerhub is of the format <main_branch>_<date> but the uploaded/stored tag is only the date, so we need to prepend the branch externally. And the branch is not always the same.
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

No branches or pull requests

1 participant