-
Notifications
You must be signed in to change notification settings - Fork 6
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
Redesign Build Deployment Process (External) #29
Conversation
Currently the branch specified - "image-push-merge" is available locally on my system. I use it to test the automated docker image push mechanism whenever any changes are merged to this branch. Once, everything looks good, need to change this to master or main as per the repo.
Had added it initially for testing purposes. Can remove now so it doesn't expose any sensitive info.
Checking in the first initial set of changes for consolidating the differences in the external and internal versions. So, the major changes only involve the image_build_push GitHub action automation to build and push images to Dockerhub whenever changes are merged to the specified branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly discussing comments that should be removed or un-commented.
# - name: docker login | ||
# run: | # log into docker hub account | ||
# docker login -u $DOCKER_USER -p $DOCKER_PASSWORD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be removed; replaced by environment variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would still need these.
The values are currently set in my forked repo's GitHub repository secrets.
For the three external repos (admin-dash, public-dash, join), these values would need to be set similar to how e-mission-server has these values set as it is the only one currently that uses a GitHub action workflow to automate the build and push for the docker image.
There is not necessarily testing to do for the changes to the external join page outside of running GitHub Actions, which we have proven to work. However, for a sanity check: I pulled the code by downloading a zip of the forked join page directory on @MukuFlash03 image-push branch. I unzipped the file, cd'ed into the main directory, and ran The containers spun up, and terminal gave the message: The internal repository builds off of the image created in our image_build_push.yml workflow. Testing the internal page and building off of the new image:
This should be similar to how the image is used internally, since docker compose is not supported. |
Wanted to add that I tried adding different config file names as get requests per the join page readme, and it worked for both the internal and external tests. |
I am not sure what this means
Given that this repo has both |
Per the docker usage policy: Per Jianli: So using compose to test internally doesn't make sense to me, since that's not what's going to happen to the image in the jenkins pipeline anyway. Using images with our changes for testing (whether built locally or pushed to docker hub via our image building actions) makes the most sense to me. |
@nataliejschultz I agree that we will not test against the images that are built using jenkins as part of our dev testing. I think that they will be tested on staging. However, We can build the internal images using |
Reverted the hardcode run_id and commented out build-push job steps. |
Will run on push to main; removed extraneous comments
Removed extraneous comments from actions yml and set it to run on push to main. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fairly straightforward
This PR serves as the implementation for this issue for redesigning our build and deployment processes across e-mission-server, join, admin-dash, public-dash primarily.
Collaborating on this along with @nataliejschultz .
All four redesign PRs for the external repos:
E-mission-server: e-mission/e-mission-server#961
Join: #29
Admin-dash: e-mission/op-admin-dashboard#113
Public-dash: e-mission/em-public-dashboard#125
A rough plan can be:
1st phase
2nd phase: