-
-
Notifications
You must be signed in to change notification settings - Fork 72
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
Rename Discussion to Welcome Session, remove deprecated TrainingRequirements #2420
Rename Discussion to Welcome Session, remove deprecated TrainingRequirements #2420
Conversation
I added some migration tests to this PR using Migration tests do run pretty slowly, so I modified our existing test setup to ignore them by default, but have them callable when needed. |
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 added some comments and I think we should discuss the approach regarding CI/CD pipeline and data migration vs seeding.
.github/workflows/cicd_main.yml
Outdated
@@ -6,7 +6,7 @@ on: | |||
push: | |||
branches: [ main ] | |||
pull_request: | |||
branches: [ 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.
File cicd_develop.yml
should be invoked for all PRs, I think. I'm not sure what this change does compared to other pipelines.
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.
This PR is against feature/instructor-checkout-changes
rather than develop
, so needs explicit inclusion in a pipeline somewhere. I'm not sure if cicd_main.yml
is the best place to do this from a semantic perspective, it was just the most convenient
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.
@elichad What is your purpose here? Do you want to be able to run complete CI/CD against a feature branch, or do you just need a CI against a feature branch?
In any case, I'd create a new file .github/workflows/cicd_feature_branch.yml
and make sure it is set against particular branch (ie. with no wildcard). We could control this pipeline from individual feature branches, for example we could easily switch off whole pipeline by changing the branches
parameter, or run only tests by disabling "CD" part in that individual file.
I would keep cicd_main.yml
untouched for now, as we want to eventually add proper CI/CD and infrastructure to the main
branch, too.
"DC Demo", | ||
"SWC Demo", | ||
"LC Demo", | ||
] |
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 want to make sure: were these migrated in production? I'm not sure what would happen if these were removed for existing users.
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.
Okay, I saw a migration removing these entries. We should not keep 2 systems for managing "static" (seeded) objects. I would suggest sticking to the seeding script, unless a data migration is actually required.
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.
Okay, I can remove that step from the migration. This is one thing I am uncertain of - are the seeding scripts run when deploying new versions to production?
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.
Good question. Let me see... I think they are not run during production deployment (but they definitely are run when deploying to test stage).
We can run them manually after deploying to production, or make sure there's a step that runs them in Ansible.
Once we switch to Docker-based production, we will run the seeds just like we do in test-amy.
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.
In general looks good, but I would like to:
- see a new pipeline for feature branches
- decide how we are going to approach running seeding in production
- discuss the migration 0259 (what is required and what is not).
.github/workflows/cicd_main.yml
Outdated
@@ -6,7 +6,7 @@ on: | |||
push: | |||
branches: [ main ] | |||
pull_request: | |||
branches: [ 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.
@elichad What is your purpose here? Do you want to be able to run complete CI/CD against a feature branch, or do you just need a CI against a feature branch?
In any case, I'd create a new file .github/workflows/cicd_feature_branch.yml
and make sure it is set against particular branch (ie. with no wildcard). We could control this pipeline from individual feature branches, for example we could easily switch off whole pipeline by changing the branches
parameter, or run only tests by disabling "CD" part in that individual file.
I would keep cicd_main.yml
untouched for now, as we want to eventually add proper CI/CD and infrastructure to the main
branch, too.
"DC Demo", | ||
"SWC Demo", | ||
"LC Demo", | ||
] |
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.
Good question. Let me see... I think they are not run during production deployment (but they definitely are run when deploying to test stage).
We can run them manually after deploying to production, or make sure there's a step that runs them in Ansible.
Once we switch to Docker-based production, we will run the seeds just like we do in test-amy.
@@ -22,13 +29,7 @@ | |||
|
|||
TRAINING_REQUIREMENTS: list[TrainingRequirementDef] = [ | |||
{"name": "Training", "url_required": False, "event_required": True}, | |||
{"name": "DC Homework", "url_required": True, "event_required": False}, | |||
{"name": "SWC Homework", "url_required": True, "event_required": False}, | |||
{"name": "Discussion", "url_required": False, "event_required": False}, |
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.
"Discussion" is not being deprecated as it's being switched to "Welcome Session". The migration 0259_...
should probably only migrate the name "Discussion" <-> "Welcome Session", without changes the seeding manages.
TrainingProgress = apps.get_model("workshops", "TrainingProgress") | ||
|
||
# migrate SWC/DC/LC specific progress to generic demo/lesson contribution | ||
# this was already done in production AMY but not in local databases |
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.
What do you mean by "local databases"? Do you mean development databases, or test-amy2 database?
This migration looks reasonable (except for lines 52-54 where Training Requirements are removed), but I'm trying to understand if it's truly needed.
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.
Development databases. When fake training progresses are created, they choose from all available TrainingRequirements, so my local dev database was populated with lots of SWC Demos, LC Homeworks, etc.
We don't have auto-generated fake data on test-amy2 so this migration isn't required there (though it would have been required if we had generated some).
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've removed the creation/deletion of TrainingRequirements from this step of the migration since that's covered by the seeding, but this section still remains for discussion.
@@ -0,0 +1,15 @@ | |||
# CI for feature branches - contains only test runs | |||
|
|||
name: CI (feature) |
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.
👍🏼
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.
Looks good. I had only 1 comment. But we have to remember about seeding in production before deploying v4.2.
"LC Homework", | ||
] | ||
DEMO_TRAININGPROGRESS_NAMES = ["Demo", "SWC Demo", "DC Demo", "LC Demo"] | ||
LESSON_CONTRIBUTION_NAMES = ["Lesson Contribution"] | ||
|
||
return self.annotate( | ||
passed_training=passed("Training"), | ||
passed_lesson_contribution=passed_either(*LESSON_CONTRIBUTION_NAMES), |
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 we use passed
instead of passed_either
with literal string "Lesson Contribution"
as an argument?
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.
Yes - this is coming in a later PR (not yet open) which updates the checkout requirements after the change from "Lesson Contribution" -> "Get Involved"
Noticed that these PRs aren't checked by CI as they're not against develop - will think about the best way to approach this
Fixes #2418
Fixes #2410