Cleanup (Public-dash) #3 - Tasks: A-1, 3 #165
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) 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.
1. Added tags as push event triggers - Github documentation for pattern matching - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#patterns-to-match-branches-and-tags - v[0-9]+.[0-9]+.[0-9]+ 2. Using github context data to select correct branch “git push” command failed in reusable workflow since it wasn’t listing any branch and by default it picked up the tag version and not any branch name. Used ${{ github.event.base_ref }} that has the source branch from which the release tag was created. - https://github.com/orgs/community/discussions/27154 - https://github.com/orgs/community/discussions/26243 Needed to extract only branch name to ignore “ref/heads/“ Added a separate job that extracts this using bash commands - https://stackoverflow.com/questions/16623835/remove-a-fixed-prefix-suffix-from-a-string-in-bash ——— 3. Using github.ref_type to check “branch” or “tag” and select correct branch When server release is created, it triggers dispatch to other workflows. However these don’t have “github.ref_type” = “tag” in this case but instead “github.ref_type” = “branch”. This case github.event.base_ref value to be empty, hence branch name extraction didn’t work. I’m using the ref_type to pass either GITHUB_REF or the extraction logic using github.event.base_ref. This is done in the workflows that call reusable workflow. The check should be fine since ref_type has only two values: branch or tag - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs
…nd not push Task A-3: Image build/push on release instead of on every push 1. Re-building on releases instead of tags - Earlier I had set the trigger event as tags but this would mean any time we create a new tag the workflow would be triggered. - Instead, we are actually creating releases and not tags through the UI. - Hence changed the trigger event to releases, specifically “published” releases. 2. Build job check added - We are now creating a new release through the reusable_image_build workflow which in turn triggers a new workflow run since the event trigger is set to run on new releases. - This check ensures that we don't have an infinite loop and this new release doesn't again trigger a workflow run. ------ Task A-1: Switch to storing images in GHCR 1. Changes to Dockerfile - Needed to add LABEL layer to ensure that the docker image is connected to the correct repository. - For dashboard images that are dependent on the server image, changed to pull from GHCR.
MukuFlash03
changed the title
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.
Third set of cleanup changes for the redesign cleanup issue
These should be merged only after the second set of PRs are merged.
Includes changes for tasks:
Task A-1: Switching to storing images in GHCR
Task A-3: Image build/push on release instead of on every push