-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add new workflow #462
Add new workflow #462
Conversation
.github/workflows/ci-cd-dev.yml
Outdated
components install kubectl && gcloud composer environments run | ||
$COMPOSER_ENVIRONMENT --location $LOCATION variables import | ||
-- gcsfuse/actual_mount_path/variables.json | ||
# deploy-to-dev: |
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.
Is this commented code copy and pasted to the new cicd? If so do you think it's worthwhile to keep it commented here or just delete it? We can also always look at git commit history for the file
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.
yep it is part of new workflow. We can 🔪 it for once
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.
Addressed in bc4e563
on: | ||
workflow_dispatch: | ||
inputs: | ||
envName: |
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.
Just wanted to confirm; does envName
get converted to inputs.env_name
?
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.
Uff no. That's my bad. Let me change it
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.
Addressed in bc4e563
09a3d0e
to
7ae39fd
Compare
get past off annotation error fool tests a bit
7ae39fd
to
7085f2f
Compare
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.
@amishas157 changes are looking good. I did have an overall design question. In your design doc, it proposed that deploys to either env (test, prod) should only come from the master
branch. This PR, however, allows the developer to deploy to test off of any branch as needed (no review required).
What were your thoughts on the dev workflow?
- Dev commits feature branch
- when ready, selects branch name and deploys to test
- deploy ci executes
Is this correct?
- name: Pytest | ||
run: pytest dags/ |
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.
I don't know how useful it is to keep the tests
job if we aren't actually running the Airflow unit tests.
In the current workflow definition, the first time that the Airflow unit tests will execute is on deploy. Is that intended?
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.
So, my plan is to remove ci-cd.yml completely. However. the tests
job is a required workflow to merge PR. Therefore, I kept it such that it passes.
Once the testing for deploy.yml
is done, I will remove this file altogether
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.
ahhhhh okie
Yes, that's still correct. I am currently using this PR to test my changes by deploying to dev. Unfortunately, github actions does not allow testing workflow before merging. One the tests look good, my plan is to create followup PR to:
|
Sounds good, thanks for clarifying |
PR Checklist
PR Structure
otherwise).
Thoroughness
What
This PR adds a new github workflow that:
This also turns off dev-to-deploy step as it is not really used currently.
Why
Improve the release workflow.
Known limitations
None