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

Rename Discussion to Welcome Session, remove deprecated TrainingRequirements #2420

Merged

Conversation

elichad
Copy link
Contributor

@elichad elichad commented May 16, 2023

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

@elichad elichad changed the title Rename Discussion to Welcome Session, remove deprecated Rename Discussion to Welcome Session, remove deprecated TrainingRequirements May 16, 2023
@elichad
Copy link
Contributor Author

elichad commented May 17, 2023

I added some migration tests to this PR using django-test-migrations - I think this is worth doing in cases where we're modifying database records during migration (i.e. not just changing fields).

Migration tests do run pretty slowly, so I modified our existing test setup to ignore them by default, but have them callable when needed.

Copy link
Contributor

@pbanaszkiewicz pbanaszkiewicz left a 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.

@@ -6,7 +6,7 @@ on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
Copy link
Contributor

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.

Copy link
Contributor Author

@elichad elichad May 30, 2023

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

Copy link
Contributor

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.

.github/workflows/test.yml Show resolved Hide resolved
"DC Demo",
"SWC Demo",
"LC Demo",
]
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

@pbanaszkiewicz pbanaszkiewicz left a 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:

  1. see a new pipeline for feature branches
  2. decide how we are going to approach running seeding in production
  3. discuss the migration 0259 (what is required and what is not).

@@ -6,7 +6,7 @@ on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
Copy link
Contributor

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",
]
Copy link
Contributor

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},
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor Author

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).

Copy link
Contributor Author

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.

@pbanaszkiewicz pbanaszkiewicz self-requested a review June 19, 2023 16:24
@@ -0,0 +1,15 @@
# CI for feature branches - contains only test runs

name: CI (feature)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏼

Copy link
Contributor

@pbanaszkiewicz pbanaszkiewicz left a 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),
Copy link
Contributor

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?

Copy link
Contributor Author

@elichad elichad Jun 21, 2023

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"

@elichad elichad merged commit 027dc20 into feature/instructor-checkout-changes Jun 21, 2023
@elichad elichad deleted the update-training-requirements branch June 21, 2023 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clean up unused options/fields in training requirements Rename Community Discussions -> Welcome Sessions
2 participants