Currently, the publish_date field on a Website object is updated at the end of a run of SitePipeline in Concourse. When the site has been successfully published, a webhook call is made back to ocw-studio that tells it to update the publish_date field for that site. The main issue with this is that the pipeline code is not exclusively triggered by user interaction. When there is a change to ocw-hugo-themes or ocw-hugo-projects a rebuild of the entire website is triggered, thus updating publish_date for every website. The issue with this is that courses that have not had any publish action by a content author have their publish_date updated, even though no actual content changes were made. This makes it impossible to determine if a course has actually had changes published to production, or if the site has simply been rebuilt using the existing content.
Plan/Design
Currently, we have draft_publish_date and live_publish_date fields on the Website model. We should:
Add draft_build_date and live_build_date as DateTimeField fields to the Website model
The update_website_status function, which is called by the pipeline_status endpoint, should update these new build date fields instead of the publish date fields
The publish_website function should be changed to update the publish date fields (draft_publish_date or live_publish_date) after Github operations have completed, setting the appropriate status based on whether it succeeds or fails
Description/Context
First, a bit of prior discussion on this topic for reference:
https://github.com/mitodl/hq/discussions/3169 https://github.com/mitodl/hq/issues/2862
Currently, the
publish_datefield on aWebsiteobject is updated at the end of a run ofSitePipelinein Concourse. When the site has been successfully published, a webhook call is made back toocw-studiothat tells it to update thepublish_datefield for that site. The main issue with this is that the pipeline code is not exclusively triggered by user interaction. When there is a change toocw-hugo-themesorocw-hugo-projectsa rebuild of the entire website is triggered, thus updatingpublish_datefor every website. The issue with this is that courses that have not had any publish action by a content author have theirpublish_dateupdated, even though no actual content changes were made. This makes it impossible to determine if a course has actually had changes published to production, or if the site has simply been rebuilt using the existing content.Plan/Design
Currently, we have
draft_publish_dateandlive_publish_datefields on theWebsitemodel. We should:draft_build_dateandlive_build_dateasDateTimeFieldfields to theWebsitemodelupdate_website_statusfunction, which is called by thepipeline_statusendpoint, should update these new build date fields instead of the publish date fieldspublish_websitefunction should be changed to update the publish date fields (draft_publish_dateorlive_publish_date) after Github operations have completed, setting the appropriate status based on whether it succeeds or fails