Set Buildkite PR job to use master and add batch1 of repos

[nkammah]

This PR that goes hand in hand with this one hooks up a few more products-docs repositories to Buildkite. On such repos, when a PR is opened or commented on (with run docs-build), the docs-build-pr job will be triggered (alongside it's Jenkins counterpart), and push preview changes to the elastic/built-docs repo under the <doc>_bk_<PR_NUMBER> branch name.

Commit statuses for the Buildkite build will be set but they are not configured to be blocking.
Additionally, the Buildkite job is configured to report back on the PR with a link to the preview and diff reports. Here's an example of such comment.

The intent in the coming days is to gain confidence in the Jenkins VS Buildkite PR docs job.

cc @brianseeders @mark-vieira for the elasticsearch repo
cc @delanni for the kibana repo
cc @thbkrkr for cloud-on-k8s
cc @kilfoyle for ingest-docs
cc @v1v / @jlind23 for beats
cc @natasha-moore-elastic for security-docs
cc @pquentin for elasticsearch-py

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 7edd85c
• Documentation preview
  • 📚 HTML diff
  • 📙 Preview

History

• 💚 Build #89 succeeded 9257542

[nkammah]

cc @brianseeders @mark-vieira I disabled the Buildkite PR bot commenting to avoid conflicts with other pipelines. Product repos longing for that commenting capability can set a GH action similar to this one or this one which can be tailored to each repo.

[gtback]

Makes sense to me, but I'd want to make sure all the content owners are aware of this change.

[joepeeples]

I disabled the Buildkite PR bot commenting to avoid conflicts with other pipelines. Product repos longing for that commenting capability can set a GH action similar to this one or this one which can be tailored to each repo.

@nkammah @gtback etc. We have a similar GitHub action for the security-docs repo, so it sounds like we'll need to modify that to include the Buildkite URLs — is that correct?

Also, how long will we continue to have both Buildkite and Jenkins running on docs PRs? Because I assume once we stop using Jenkins, we'd need to modify our GH action again to remove the Jenkins preview URLs.

[nkammah]

Also, how long will we continue to have both Buildkite and Jenkins running on docs PRs? Because I assume once we stop using Jenkins, we'd need to modify our GH action again to remove the Jenkins preview URLs.

Yes for now we will have both running to gain confidence in the Buildkite setup - we'll also need your help to validate that setup. We do need to move forward promptly as the docs jobs on elasticsearch-ci is what's holding that Jenkins instance decomissioning date.

[kilfoyle]

LGTM for the ingest docs. 👍

[nkammah]

I disabled the Buildkite PR bot commenting to avoid conflicts with other pipelines. Product repos longing for that commenting capability can set a GH action similar to this one or this one which can be tailored to each repo.

@nkammah @gtback etc. We have a similar GitHub action for the security-docs repo, so it sounds like we'll need to modify that to include the Buildkite URLs — is that correct?

Ha yes - touché !

Also, how long will we continue to have both Buildkite and Jenkins running on docs PRs? Because I assume once we stop using Jenkins, we'd need to modify our GH action again to remove the Jenkins preview URLs.

I'm hoping not much time - a week? 2?

[brianseeders]

Does @elastic/ci-systems have monitoring in place for github api request rate limiting for elasticmachine? I would say it would be good to have in place before you start rolling this out, as the pr-bot will start using more API requests for each additional repo

[nkammah]

@brianseeders - yes it's here per doc