Gitea Download Windows
Cris Dwellingham
token is used for authentication and identification, such as P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23.It is one-time use only and cannot be used to register multiple runners.You can obtain tokens from your_gitea.com/admin/runners.
You can upload it as a file with the extension .yaml in the directory .gitea/workflows/ of the repository, for example .gitea/workflows/demo.yaml.You might notice that this is fairly similar from the Quickstart for GitHub Actions.That is because Gitea Actions is designed to be compatible with GitHub Actions wherever possible.
You can use github.xyz and Gitea will work fine.As mentioned, Gitea Actions is designed to be compatible with GitHub Actions.However, we recommend using gitea.xyz in case Gitea adds something that GitHub does not have to avoid different kinds of secrets in your workflow file (and because you are using this workflow on Gitea, not GitHub).Still, this is completely optional since both options have the same effect at the moment.
You may be aware that there are tens of thousands of marketplace actions in GitHub.However, when you write uses: actions/checkout@v3, it actually downloads the scripts from gitea.com/actions/checkout by default (not GitHub).This is a mirror of github.com/actions/checkout, but it's impossible to mirror all of them.That's why you may encounter failures when trying to use some actions that haven't been mirrored.
When you use some actions like actions/checkout@v3, the act runner downloads the scripts, not the job containers.By default, it downloads from gitea.com, so it requires access to the internet.It also downloads some docker images from Docker Hub by default, which also requires internet access.
The webhook currently supports pushes and pull requests by default, but you cansubclass buildbot_gitea.webhook.GiteaHandler to add supports for other events,and then use your subclass by setting the class parameter:
The change source is part build step to clone a gitea repository. It includes features to build a pull request, if the pull request can be merged without conflicts. This needs to be used in conjunction with a gitea change_hook and have it send pull request updates in order to be able to handle pull requests.
All I really care about is that I could use git to watch for changes that I can track, etc, and then push to my production repo when I am done developing them. gitea seems like it might be the way to go.
I have a home-lab that i use to try new things out, alot of what I do is overkill for what I need, but it lets me learn and develop (thats what a homelab is for after all)
I have a web server with a few websites i host, i installed gitea on it on a separate port, and run it all though haproxy to allow for port remapping based on hostname (give my git server a url that isnt a custom port)
and so I can learn load-balancing later on for web and databases
I did a curl between servers, and got 200OK back for my webserver, but when i put my port in for the git it just sits there waiting
I then did a curl from my windows pc to the webserver and got 200 back from the webserver and 302 for the git server
At this point im not using a proxy, thats what im trying to troubleshoot by using curl
my webserver is an apache server, and git is gitea
Both hosted on the same physical server
There is no firewall between the proxy server (where im curling from) and the web/git server (where im curling to)
Both are on the same network (as I can ping and curl to apache fine, just not git)
So yes, something is misconfigured somewhere, i just have no idea where
My thought would be its my proxyserver but I dont know why curl to 80 works fine but 3000 doesnt
It means apache server is not returning any response. It might be it is not listening on that port or that you block it. For first case, any other machine should get the same error including windows and when you are curling on the server machine itself.
Im trying to setup the reverse proxy
I have a HAproxy server which im trying to use to convert a hostname into host:port
But HAproxy was showing the server as offline even though i could access it fine from my windows pc via the web interface
so i did a curl from the HAproxy server to see what was going on and found that I can curl to my apache install on my webserver but not to my git install on the same webserver
(two services, same server)
Gitea is responding fine to responses from localhost and from my windows pc
Just not to the HAproxy server
I think I made a mistake. Seems like it is 100% your computer firewall in control of which ip you can reach your web server. I am pretty sure it is a misconfiguration in the firewall if your windows machine can reach it while your Linux machine can't.
Don't use haproxy then. Use your apache as the proxy instead or don't use any proxy at all and directly have gitea listening on port 3000 and Curl that port from another machine in the network. See if that helps. If everything works, you can then pinpoint the problem to the proxy.
- setting up the DNS for the domain gitea.mydomain.com to point to my public IP address
- setting up a CAA record for gitea.mydomain.com authorising Lets Encrypt to issue a certificate
- port forwarding 443 on my router to 8443 on the PC running Gitea (which Gitea listens on)
Weblate has support for Gitea webhooks, add a Gitea Webhook forPush events event with destination to /hooks/gitea/ URL on yourWeblate installation (for example ).This can be done in Webhooks under repository Settings.
760c119bf3