SW-8282 Port web-components CI workflow to Buildkite

[constanzauanini]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
web-components	Ready	Preview, Comment	Jun 1, 2026 1:35pm

[github-actions]

To increment version on merge, please add one of patch (default), minor, or major label to this PR.

[tommylau523]

I think we should probably add release-notes post to this too! It will be helpful in the long run.

[ice1080]

I think we should probably add release-notes post to this too! It will be helpful in the long run.

@tommylau523 @constanzauanini does this mean that every time a PR is merged in this repo it generates a slack message and transitions Jira tasks, since every PR creates a new tag?

[tommylau523]

I think we should probably add release-notes post to this too! It will be helpful in the long run.

@tommylau523 @constanzauanini does this mean that every time a PR is merged in this repo it generates a slack message and transitions Jira tasks, since every PR creates a new tag?

​I guess so. Perhaps we can update it to not for Patch, but for Minor/Major package updates only, if it gets overbearing. But I don't think we make too many changes to our web-components repo and each package push to npm is technically a release.

[ice1080]

​I guess so. Perhaps we can update it to not for Patch, but for Minor/Major package updates only, if it gets overbearing. But I don't think we make too many changes to our web-components repo and each package push to npm is technically a release.

I think I might request that this is done in a separate PR, just to separate concerns. I feel like this repo doesn't need an unreleased.log file, it probably doesn't need Jira transitions, etc

[ice1080]

Do we need a publish-rc.yaml equivalent in buildkite if we're doing our other publishing in buildkite?

[constanzauanini]

​I guess so. Perhaps we can update it to not for Patch, but for Minor/Major package updates only, if it gets overbearing. But I don't think we make too many changes to our web-components repo and each package push to npm is technically a release.

I think I might request that this is done in a separate PR, just to separate concerns. I feel like this repo doesn't need an unreleased.log file, it probably doesn't need Jira transitions, etc

We didn't have unreleased log, release-notes and jira transitions before. I can remove all that for now and make this PR include just the migration to buildkite. If we want any of those new scripts later, we can open new PRs.

[constanzauanini]

Do we need a publish-rc.yaml equivalent in buildkite if we're doing our other publishing in buildkite?

I didn't do it because publish-rc fires on a "publish rc" PR comment and Buildkite has no native PR-comment trigger. So I left just that in github actions

[tommylau523]

Do we need a publish-rc.yaml equivalent in buildkite if we're doing our other publishing in buildkite?

I didn't do it because publish-rc fires on a "publish rc" PR comment and Buildkite has no native PR-comment trigger. So I left just that in github actions

​If we want to consolidate our build enviornment on Buildkite only, we can likely setup a webhook trigger on Buildkite for the publish-rc pipeline, and setup GitHub Actions to purely fire a webhook.

The pro is to have the same build enviornment as the rest of the pipeline. The con is that we will have to manage two pipelines for one action in that case.

[ice1080]

Just one open question, but approving for now to unblock