kosmos/gitea.kosmos.org
kosmos/gitea.kosmos.org
Archived
8
1
Fork 0
Code Issues Pull Requests Releases Activity

Add documentation about updating Gitea #13

Merged
raucao merged 2 commits from docs/update into master 2019-01-28 22:42:18 +00:00
Conversation 3 Commits 2 Files Changed 1 +28
1 changed files with 28 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/kubernetes.md
View File

@ -41,3 +41,31 @@ Kubernetes before uploading them again. This is done by this script:
> @whitecolor, in your case you should be fine by clearing `PV.Spec.ClaimRef.UID` in the PV. Only the re-created PVC (with any UID) can then use the PV. And it's your responsibility that only the right person can craft appropriate PVC so nobody can steal your data. > @whitecolor, in your case you should be fine by clearing `PV.Spec.ClaimRef.UID` in the PV. Only the re-created PVC (with any UID) can then use the PV. And it's your responsibility that only the right person can craft appropriate PVC so nobody can steal your data.
https://github.com/kubernetes/kubernetes/issues/48609#issuecomment-314066616 https://github.com/kubernetes/kubernetes/issues/48609#issuecomment-314066616
## Update Gitea
### Released version
Change the image for the gitea-server container
(`kubernetes/gitea-server.yaml`) to `gitea/gitea:TAG`, for example:
`gitea/gitea:1.7.0-rc2`
### Unreleased version
This is useful to deploy features that are in master but not yet in a release.
raucao commented 2019-01-08 23:40:25 +00:00
Review
Copy Link

You mean like gitea/gitea:latest? If we never want to deploy our own code, then we never have to use our own repo afaics. But we do want to be able to deploy our own code.

You mean like `gitea/gitea:latest`? If we never want to deploy our own code, then we never have to use our own repo afaics. But we do want to be able to deploy our own code.
greg commented 2019-01-25 12:22:51 +00:00
Review
Copy Link

Yes, but a copy of gitea/gitea:latest at the revision we want, instead of always keeping up with their latest. Creating our own images should be a separate issue

Yes, but a copy of `gitea/gitea:latest` at the revision we want, instead of always keeping up with their latest. Creating our own images should be a separate issue
$ docker pull gitea/gitea
raucao commented 2019-01-08 23:36:25 +00:00
Review
Copy Link

Pretty sure creating orgs is not part of the update process. This should be done before documenting how to update anything imo.

Pretty sure creating orgs is not part of the update process. This should be done before documenting how to update anything imo.
raucao commented 2019-01-09 07:02:54 +00:00
Review
Copy Link

Obsolete comment. Already explained in PR description as TODO.

Obsolete comment. Already explained in PR description as TODO.
$ docker tag gitea/gitea:latest kosmosorg/gitea:production
$ docker push kosmosorg/gitea
raucao commented 2019-01-08 23:41:55 +00:00
Outdated
Review
Copy Link

This is missing the build step for our own image. But also, we should build on Drone CI anyway, as discussed.

This is missing the build step for our own image. But also, we should build on Drone CI anyway, as discussed.
Set the image for the gitea-server container to `kosmosorg/gitea:latest`, or run
this command to force a deployment if it is already set to it
$ kubectl patch deployment gitea-server -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
raucao commented 2019-01-08 23:42:47 +00:00
Review
Copy Link

Set the image where? And also why wouldn't we always use the same tag to be deployed; isn't that what they're for? So that we only have to tag an image, not change Kubernetes config?

Set the image where? And also why wouldn't we always use the same tag to be deployed; isn't that what they're for? So that we only have to tag an image, not change Kubernetes config?
raucao commented 2019-01-09 07:03:53 +00:00
Review
Copy Link

I'd propose a tag like production, similar to the Git tags/branches we're using elsewhere.

I'd propose a tag like `production`, similar to the Git tags/branches we're using elsewhere.
greg commented 2019-01-25 12:29:13 +00:00
Review
Copy Link

It depends, I think sometimes we'll want to use releases, so official images, and sometimes we'll want an unreleased feature. production tag sounds good

It depends, I think sometimes we'll want to use releases, so official images, and sometimes we'll want an unreleased feature. `production` tag sounds good
raucao commented 2019-01-26 02:20:25 +00:00
Review
Copy Link

The question about how/where to "set the image to x" is still unanswered by the doc.

The question about how/where to "set the image to x" is still unanswered by the doc.
greg commented 2019-01-28 16:29:33 +00:00
Review
Copy Link

This is still the old commit because we're commenting on it, new content is:

Change the image for the gitea-server container
(`kubernetes/gitea-server.yaml`) to `gitea/gitea:TAG`, for example:
`gitea/gitea:1.7.0-rc2`
This is still the old commit because we're commenting on it, new content is: ``` Change the image for the gitea-server container (`kubernetes/gitea-server.yaml`) to `gitea/gitea:TAG`, for example: `gitea/gitea:1.7.0-rc2` ```
raucao commented 2019-01-28 22:40:47 +00:00
Review
Copy Link

Oh, looks like Gitea's "show outdated" thing is not applied correctly then. Thanks.

Oh, looks like Gitea's "show outdated" thing is not applied correctly then. Thanks.
### Build our own image
At the root of the [https://github.com/go-gitea/gitea](gitea repo)
$ DOCKER_TAG=production DOCKER_IMAGE=kosmosorg/gitea make docker # builds and tags kosmosorg/gitea:production locally
$ docker push kosmosorg/gitea