Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/website/go.dev/_content/blog: auto-deploy latest master version #36707

Closed
dmitshur opened this issue Jan 23, 2020 · 5 comments
Closed

x/website/go.dev/_content/blog: auto-deploy latest master version #36707

dmitshur opened this issue Jan 23, 2020 · 5 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unreleased

Comments

@dmitshur
Copy link
Contributor

Currently, when a blog post is being published to blog.golang.org, it needs to go through code review in Gerrit, get +2ed, and then submitted to the master branch. Afterwards, someone on the @golang/osp-team needs to manually redeploy the blog.

Even though the process to deploy the blog has been simplified, it's still manual effort and a context switch. It requires more coordination.

I propose we automate this process so that the latest master commit of x/blog repo is always published to blog.golang.org. That will mean to publish a new blog post, one needs only to submit the Gerrit change. Fixing up typos can also be done by fixing the master branch, and not require additional redeploys.

This can be implemented by reusing the golang.org/x/build/cmd/tip server that does automatic deploys for tip.golang.org and talks.golang.org.

Thoughts?
@dmitshur dmitshur added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 23, 2020
@dmitshur dmitshur added this to the Backlog milestone Jan 23, 2020
@toothrot
Copy link
Contributor

This is great. Hopefully it is as easy as the simple master scenario from #32606.

@dmitshur
Copy link
Contributor Author

dmitshur commented Mar 27, 2020 •
edited

An update on this issue. I brought it up and discussed it while talking with @rsc today.

We were in agreement that doing this should be reasonable, given some pre-conditions:

  • we should create a separate permission group for people who can +2/submit CLs in x/blog instead of reusing the same group of people who have +2/submit rights for code in all other repos
  • we should communicate this change clearly to those people before it is implemented, so that everyone who is responsible for publishing blog posts is aware that submitting a post CL to master branch will cause it to be auto-deployed

Based on that conversation and the 👍 reactions from @toothrot, @cagedmantis, and @bcmills, I think it should be reasonable to move this issue from NeedsDecision to NeedsFix state. I'll wait 7 days to give people a chance to comment further before doing that.

Implementation details can be investigated and discussed after we agree that it is okay auto-deploy latest master blog content. Some of the options available include reusing golang.org/x/build/cmd/tip's auto-deploy functionality (keeping #38120 in mind), reusing the playground's auto-deploy approach as @toothrot suggested in the comment above, or coming up with something else.

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jul 7, 2020
@dmitshur dmitshur modified the milestones: Backlog, Unreleased May 21, 2021
@dmitshur
Copy link
Contributor Author

Russ is making progress towards this now, CL 321670 being one step.

@dmitshur dmitshur changed the title x/blog: auto-deploy latest master version x/website/go.dev/_content/blog: auto-deploy latest master version Sep 16, 2021
@gopherbot
Copy link

Change https://golang.org/cl/367994 mentions this issue: website: update deploying sections in README files

@gopherbot
Copy link

Change https://golang.org/cl/368366 mentions this issue: website: publish all commits, eliminating Website-Publish+1 vote

gopherbot pushed a commit to golang/website that referenced this issue Dec 6, 2021
@dmitshur
website: update deploying sections in README files
577a9fd 
Use the README in cmd/golangorg directory as the canonical location
for documenting the deployment process for websites served by that
command. The top-level README now redirects to it, just like the
README in tour directory.

Add more context on how the website uses tests to ensure that deploys
can be done safely.

While here, also shorten various URLs to use the new go.dev domain.

For golang/go#36707.
Updates golang/go#39687.

Change-Id: If5cf7a74b19830540b29612de37286c5f14244a1
Reviewed-on: https://go-review.googlesource.com/c/website/+/367994
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
@rsc rsc removed their assignment Jun 23, 2022
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
@passionSeven
website: update deploying sections in README files
55cef73 
Use the README in cmd/golangorg directory as the canonical location
for documenting the deployment process for websites served by that
command. The top-level README now redirects to it, just like the
README in tour directory.

Add more context on how the website uses tests to ensure that deploys
can be done safely.

While here, also shorten various URLs to use the new go.dev domain.

For golang/go#36707.
Updates golang/go#39687.

Change-Id: If5cf7a74b19830540b29612de37286c5f14244a1
Reviewed-on: https://go-review.googlesource.com/c/website/+/367994
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
@passionSeven
website: publish all commits, eliminating Website-Publish+1 vote
0fce86f 
The main point of Website-Publish+1 was to manually avoid
a race in Cloud Build when multiple commits land. But now
cmd/locktrigger takes care of that race automatically, so there
is little point to Website-Publish+1 now. Stop looking for it.

(If a commit landed without Website-Publish+1, it would still be
published with the next Website-Publish+1 commit, so it was
no real restriction on who can publish content.)

I considered adding a rule like "DO NOT PUBLISH" in a commit
message means not to publish the commit, but once it lands,
again the next publishable commit is going to publish all
previous commits, so even the possibility of landing such commits
puts the repo in a very fragile state.
Better not to support that idea at all.

Fixes golang/go#36707.

Change-Id: Icfe3bcdb0003608ff84bb300c43b61b542236571
Reviewed-on: https://go-review.googlesource.com/c/website/+/368366
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@toothrot @rsc @dmitshur @gopherbot