Make gitea official url be gitea.osgeo.org

[strk]

And drop a redirect from git.osgeo.org/gitea to gitea.osgeo.org

The reason for using the subdir was a least-change approach to infrastructure. Nowadays it looks like we are more flexible in how we do things...

[lnicola]

Should we stick to git.osgeo.org? That way it might still work if we ever switch from Gitea to whatever fork gets popular next.

[robe]

I'm thinking that too that we should just call it git.osgeo.org. That way my SSH won't change too.

[strk]

There are distinct configuration directives for the SSH host and the HTTP base url so you don't need to change the SSH remote.

And we have HTTP redirects so there's no urge to change your HTTP remote either (git.osgeo.org/gogs still work as a remote). For the same reason shall we move to another hoster we'll still be able to use redirects so I continue thinking gitea.osgeo.org is a good name. The git.osgeo.org url could still redirect there as it does now (possibly in a direct way)

[robe]

I suppose since we have gitea.osgeo.org already working it's okay to keep it. I don't think the redirect thing is that seamless though. Like I'm sure weblate will complain if I don't change the postgis links to the gitea.osgeo.org cause I recall it not liking redirects.

So I'm just a little concerned of the services we have that might break. I suppose if things go bad it would be just flipping the switch from gitea.osgeo.org back to git.osgeo.org/gitea.

[strk]

Moving gitea install to root-path will also have the benefit of making webfinger work, which is currently broken:

• ​https://webfinger.net/lookup/?resource=strk%40git.osgeo.org
• ​https://webfinger.net/lookup/?resource=strk%40gitea.osgeo.org

Laurențiu see also the webfinger implications in the name, would you want it to be lnicola@… or lnicola@… to follow your activity in the osgeo git hoster ? And let's also consider the case in which we want to test another git hoster, which happened in the past (we tested gitlab)

See how webfinger works on the gitea.com deploy:

• ​https://webfinger.net/lookup/?resource=strk%40gitea.com

[lnicola]

I'd prefer lnicola@… or lnicola@…. If you decide you like Forgejo more, the URLs can stay unchanged.

[lnicola]

Lol, osgeo.org or git.osgeo.org.

[strk]

The problem I see with @osgeo.org is that there are different "facets" of you, so I might want to follow the "gitea committer" facet of you while not following the "video poster" or "photo poster" you.

[lnicola]

Yeah, that's understandable. git.osgeo.org is fine.

[strk]

We settled with lnicola (on #sac:osgeo.org) about:

• git.osgeo.org becoming a redirect to gitea.osgeo.org (instead of git.osgeo.org/gitea)
• gitea.osgeo.org becoming the official url of the Gitea OSGeo service

[robe]

I'm just worried how much stuff is going to break, but I guess the longer we wait the more painful the break.

So I guess our sshs will all be git@… though I imagine git@… will still work right?

[strk]

You can test right now if git@… works as a remote. It works for me:

$ git config remote.origin.url git@gitea.osgeo.org:sac/ansible-deployment.git
$ git fetch origin
$ git config remote.origin.url git@git.osgeo.org:sac/ansible-deployment.git
$ git fetch origin
$

I didn't change any official names

[strk]

Regina is there a procedure to re-create the gitea staging container from the production one ? I'd like to test the configuration change but currently staging is using a newer version of Gitea which is incompatible with both the database and the configuration we're using

[robe]

Replying to strk:

You can test right now if git@… works as a remote. It works for me:

$ git config remote.origin.url git@gitea.osgeo.org:sac/ansible-deployment.git
$ git fetch origin
$ git config remote.origin.url git@git.osgeo.org:sac/ansible-deployment.git
$ git fetch origin
$

I didn't change any official names

Yah it should work since gitea.osgeo.org points at the same ip and port 22 for the secondary ip is allocated for tracsvn.

Regarding the redeploy of tracsvn, if you don't care about data, you should be able to roll it back before I upgraded by doing

` lxc restore tracsvn-dev reset

`

I just did that but something is wrong - it is now at what production was so should be the same version, but the login page is giving me a can't load asset thing. I'm assuming that is something in your new staging script?

I just did that so should be the same version as production now.

But to build direct from production backup, that's a bit more involved

You have to completely delete the container first and then run thru

deployment/roles/staging/tasks/build-tracsvn-dev.yml

I usually have to run it twice cause of some sequencing issue.

[strk]

Ok the gitea configuration was now deployed via ansible for both staging and production environments, using this:

ANSIBLE_CONFIG=ansible.osgeo.staging.cfg ansible-playbook deployment/deploy-gitea.yml
ANSIBLE_CONFIG=ansible.osgeo.prod.cfg ansible-playbook deployment/deploy-gitea.yml

Each run deployed to 2 different hosts, as per inventory:

• The one running Gitea (osgeo3-tracsvn, osgeo4-tracsvn-dev)
• The one running ngnix proxy (osgeo4-nginx, osgeo7-nginx)

But the role is not yet full because a staging domain is missing for the gitea.osgeo.org.

As discussed on IRC it could be a good idea to have all staging domains fall under the "dev.osgeo.org" (or "stage.osgeo.org" which is longer but matches the scope more).

I'll let you decide but at the end we need:

• git.<stage>.osgeo.org
• gitea.<stage>.osgeo.org

Doing that via ansible (see #3188) would be great but I will not wait on that.

[strk]

Milestone renamed