Cleanup (Server) #2 - Tasks: A-4, 5 #985
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Refer to details in cleanup issue: Task A-6: e-mission/e-mission-docs#1082 (comment)
Refer to details in cleanup issue: Task A-2: e-mission/e-mission-docs#1082 (comment) Storing server tag as well so that artifacts are not needed. Can also remove image tag passed as input in Workflow dispatch POST request. Workflow input also removed in dashboard workflows For now not removing artifacts until the internal script is updated to handle this change. ---- 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.
…ally 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.
Approach: Converted test-with-docker and test-with-manual-install to reusable workflows. Added them as jobs in image_build_push workflow. Build job in this workflow needs these test jobs as dependencies. ------- Test Workflow run https://github.com/MukuFlash03/e-mission-server/actions/runs/11096277197/job/30825929886 ----- Notes Github actions didn't have out of the box solution for running a workflow based on results of multiple workflows where ALL workflows must have completed successfully. We need this since both the test-with-docker and test-with-manual-install must pass. So this needs an "AND" logic. "workflow_run" is there but this triggers the dependent workflow when either of the workflow dependencies defined as prerequisites are completed. So this has an "OR" logic. https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run ---- Found an alternative suggestion here: https://stackoverflow.com/a/75597437 This suggests converting the pre-requisite workflows into reusable workflows. These workflows can then be called in jobs in the workflow that needs these workflows to be run before. Finally, these jobs can be added as dependencies for the requisite job. In our scenario, two new jobs are added to the image_build_push.yml for each of the two tests environments. These will run parallelly. Then in the build image job, these jobs are added in the "needs" field, indicating that these jobs must pass successfully before running the build job. ------- Also corrected the branch in reusable workflow for fetching latest server image tag. Need to update in the currently open PRs as well. ------ Also, removed the `push` trigger from the two `test` workflows since the `image_build_push` workflow would also be triggered on a `push` event which in its workflow triggers these two test workflows. Thus if not removed, each test workflow would run twice.
14 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Task A-4: Run image_build_push only after tests pass successfully