microsoft
build: update build-docs website deployment to scheduled pipeline
Moved website deployment step from build-docs to separate pipeline which triggers daily 8PM PST.
Can we publish the site more frequently than once a day? I expect we will constantly get questions like, "i just made a docs change; when can I see it on ff.com?" I'd really like the answer to NOT be "wait ~24 hours and if it's not right, make another change and wait another 24 hours."
Can we publish the site more frequently than once a day? I expect we will constantly get questions like, "i just made a docs change; when can I see it on ff.com?" I'd really like the answer to NOT be "wait ~24 hours and if it's not right, make another change and wait another 24 hours."
That makes sense, do you think every hour might be more appropriate for the schedule?
Can we publish the site more frequently than once a day? I expect we will constantly get questions like, "i just made a docs change; when can I see it on ff.com?" I'd really like the answer to NOT be "wait ~24 hours and if it's not right, make another change and wait another 24 hours."
Not arguing with having it run more frequently than every 24 hours, but note that devs can always do a manual run of the pipeline if they want to see their docs sooner. So every few hours might be a reasonable frequency?
I understand that a scheduled run is simple, but is there no event-oriented design we could use here? Could every main branch commit that touches the docs folder result in a docs build, for example, in addition to the scheduled run? For comparison, the main-next job was run on a schedule, but it was also triggered by a next branch commit. That meant that in practice, the job would run immediately after the main/next PR was merged - because that created a commit in next.
I understand that a scheduled run is simple, but is there no event-oriented design we could use here? Could every main branch commit that touches the docs folder result in a docs build, for example, in addition to the scheduled run? For comparison, the main-next job was run on a schedule, but it was also triggered by a next branch commit. That meant that in practice, the job would run immediately after the main/next PR was merged - because that created a commit in next.
Yeah, triggering off of changes to docs still makes sense and sounds like a good idea. It won't catch changes to API documentation, but it will catch direct changes to website infra and our manually created documentation. And then we have the scheduled trigger (or on demand via ADO UI) to capture API docs changes.
It won't catch changes to API documentation,
We could also trigger off of changes to the api-extractor generated reports.
Nit: for your PR title, I would probably use ci or build instead of docs, since this actually changes pipeline / deployment behaviors, and not just documentation changes.
A few small things below. I'm still concerned about the fact that the Azure function won't work though, because we haven't addressed the issue of
versions.jsonnot being present in docs/api.
There were some recent changes to the docs/api/fallback/index.js such that it doesn't reference versions.json anymore. I merged the latest changes into this branch so I think there shouldn't be any referencing issues anymore. Currently, the build-docs pipeline publishes docs/api as a separate artifact.
Updated the secure development steps to the build-docs-website-deploy pipeline.
Also, I ended up removing the scheduled pipeline since it seems to make more sense to trigger off of changes on main and release branches. For now, this pipeline will only trigger off of changes to main since we don't want to deploy documentation changes to old release branch versions. Once we have tracking for the latest release minor versions: https://dev.azure.com/fluidframework/internal/_workitems/edit/6739/, we can start triggering this pipeline on main as well as latest minor. Until then, I think it makes most sense to only trigger on main.
@zhenmichael Any status update on this? I just got a staleness notification for this PR. I think it's important we get this in before 2.0 GA.