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 (Public-dash) #2 - Tasks: A-5 #161

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

MukuFlash03
Copy link
Contributor

Second set of cleanup changes for the redesign cleanup issue
These should be merged only after the first set of PRs are merged.

Includes changes for tasks:
Task A-5: Reusable workflows for unifying workflows to reduce duplicated code

Mahadik, Mukul Chandrakant and others added 6 commits September 20, 2024 23:42
Refer to details in cleanup issue:
Task A-2: e-mission/e-mission-docs#1082 (comment)

Added .env file initialized with the current latest tag of admin-dash and server image.
Internal script can read docker image tags directly from .env.tags using curl to fetch raw file contents.
Storing server tag as well since admin-dash Dockerfile uses it.

Removed workflow dispatch inputs
No longer need inputs since reading from .env.tags in server repo directly

------

Read raw file contents directly instead of using REST API
REST API endpoint returns base64 encoded data which then needs to be decoded.
Can simply read the Raw file contents from the publicly available file.

------

Also changed tag name to match tag name in internal repository
This way we can directly use the tag name without having extra fields like envVar in the internal script.

-----

For now not removing artifacts until the internal script is updated to handle this change.
…ternal

Task A-8: Prefixing branch name to the docker tag along with the date.
In the internal script we will not need to maintain the different branch lists as the images will be completely tagged in the external workflows themselves.
We can simply use the tags without modifications then.

For now, not prefixing the tag to the artifact since we will be removing the artifact anyways.
And current internal script works with artifacts.
Once I update the internal script, will come back and remove artifacts.
Also removing prefixed branch name from frontend image artifact in case of workflow dispatch event since it uses the existing frontend image tag generated during push event which already has prefixed branch name

In Dockerfile, removing hardcoded branch name, since in this change, we are already included the branch name in image tag.

----------

Task A-7: Certifcates added to internal Dockerfiles.

Refer to issue comment for details:
Task A-7: e-mission/e-mission-docs#1082 (comment)

The certificates are relevant to our internal AWS configuration and not needed externally.
They can be present externally too without having any major effect.
But removing them helps keeping the base image clean.
Additionally, anyone working with the code can customize with their own certificates if needed or adopt an approach which doesn't even need certificates in the first place.
Internal script updated as well.
Internal PR must be merged as well once these external PR changes merged.
Storing a reusable workflow in the e-mission-server repo. Can decide where to place it in a central location.
https://docs.github.com/en/actions/sharing-automations/reusing-workflows

It essentially works like a function call in normal programming.
The advantage is that we have no repeated code the image build process.
All the other repos (join, admin-dash, public-dash) reuse the same workflow file.

Additionally, on for future GitHub actions, workflow file related changes, will no longer need to have 3 additional PRs for each repo (join, admin-dash, public-dash). Can simply modify the reusable workflow file as this is the core “function” workflow that is being called.

I have added conditional checks that check for the repo name in the reusable workflow file that determine which statements to execute depending on for which repo the workflow is running.

This is used for both push events specific to a repo as well as for the workflow dispatch events triggered on pushes to server repo.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ready for review by Shankari
Development

Successfully merging this pull request may close these issues.

1 participant