Repository navigation
[chore] ci: publish qa builds of release lines and tagged prs to github pages - #129
Merged
Merged
Conversation
…ages, with a helper to tag a pr
|
…or overwrite each other, and refuse previews of prs that change .github
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ref: BRU-5035
QA builds now publish to GitHub Pages on their own. Today every deploy for QA is a manual run in the closed builder repo, so this automates that first step. Staging (regression) and production stay on the builder.
Every push to a
release/**branch publishes that line tohttps://usebruno.github.io/bruno-api-docs/release-vX.Y.Z/. For an urgent check on a PR,scripts/pages-preview.sh <pr>tags its headpreview/pr-<n>and it publishes to/pr-<n>/.Why GitHub Pages: it comes free with the repo, so there's no AWS setup or extra keys to manage.
The build uses the same commands and
Bruno.build/version.jsonstamp as the builder repo, so it works on 0.5.x and on the 0.6.0 package split. Each deploy only replaces its own folder andgh-pagesstays a single commit, so its history doesn't grow. The run goes green only once Pages serves the new sha.Note:
.github/. If you push apreview/pr-*tag by hand, review the PR's.github/changes first.release/v0.5.1andrelease/v0.6.0.gh-pagesbranch.Checked by running the publish step against a local bare repo: first deploy, redeploy of the same line, and five deploys racing at once all land with one commit on
gh-pages. The helper refuses this PR (it changes.github/) and pushes no tag.