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 (Admin-dash) #3 - Tasks: A-1, 3 #140

Closed
wants to merge 8 commits into from

Conversation

MukuFlash03
Copy link
Contributor

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

Mahadik, Mukul Chandrakant and others added 8 commits September 20, 2024 22:23
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.

-----

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.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Tasks completed
Development

Successfully merging this pull request may close these issues.

2 participants