-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
An internal CI/CD system compatible with Github actions workflow yaml syntax, action yaml syntax and most action plugins #13539
Comments
tips about api for ci tools to repot detail message:
{
commit: xxxxxxx
path: "xxxxx/xxxxx",
line: -1,
type: bug/ security/ codesmell/ info,
detail: xxxxxxx,
provider: xxxxx,
}
{
commit: xxxxxxx
path: "xxxxx/xxxxx",
group: golang, // only data in same group will be calculate together
provider: xxxxx,
start_line: xx,
start_cols: xx,
end_line: xx,
end_cols: xx,
matched: 0 -- not, .>1 -- yes
} do some calculate and show some usefull data on ui.
{
commit: xxxxxxx
step_name: aaa,
parent_step_name: bbb,
previous_step_name: ccc,
log: xxxxx, or link to log data
status: pending or runing or success ....
} |
Can you clarify what this will entail? Would this mean GitHub Actions could run on a github.com mirror of a repo and the results would appear on a Gitea server? |
That means Github actions could be running on Gitea(with this CI feature) servers(actually on user's agent, Gitea will only a coordinator and result saver). |
Would this be implemented by explicitly checking for a |
@moqmar Global webhooks have been implemented. The issue is to be compatible with actions for those migrations from github. |
I have been working on an external webhook endpoint for github actions self-hosted runners to use with my gitea instance or locally on any pc. This is basically a fork of the runner to be able to reuse their code for a missing aspnetcore server. During my tests I was able to use gitea almost like a ghes instance, some actions like I would be glad to see endpoints for CI logs and have an integrated UI. Currently I have a basic react UI to display my logs, added as an external tab to gitea. Experimental Usage Setup Gitea as an ghes endpoint, file "Runner.Server": {
"GitServerUrl": "https://gitea:3042",
"GitApiServerUrl": "https://gitea:3042/api/v1",
"GitGraphQlServerUrl": null,
"GITHUB_TOKEN": "Add your personal access token here",
"ActionDownloadUrls": [
{
"TarballUrl": "https://gitea:3042/{0}/archive/{1}.tar.gz",
"ZipballUrl": "https://gitea:3042/{0}/archive/{1}.zip"
}
]
} Add Setup https and use openid connect with gitea (Optional for Security, only working if the github actions server is using https)
"Kestrel": {
"Endpoints": {
"HttpsFromPem": {
"Url": "https://*:5001",
"Certificate": {
"Path": "./cert.pem",
"KeyPath": "./key.pem"
}
}
}
},
"ClientId": "ClientId of your Oauth app",
"ClientSecret": "Client secret of your Oauth app",
"Authority": "https://gitea:3042", Add Start Configure self-hosted runners, https://github.com/ChristopherHX/runner.server#advanced-usage EDIT 2021/10/26
|
@ChristopherHX whoa! That's amazing!! |
This seems nice |
Being able to store the configuration in a custom branch would help a lot for adding automation to open source projects that don't want to have specific CI files added to the core repo. The linux kernel for instance. |
Maybe we can have some options:
|
I actually really like the idea of having a seperate repo analogous to the wiki repository for this. Would be interesting to explore other functionality that could be implemented in this way. |
Yup now I've been exploring more, I can see a separated repo for the workflows could be a very helpful way of doing this too. Then multiple repos (mirrors, forks, or separate repos for separate developers) can point to common workflow actions. |
Maybe after artifact upload is done, basic code intelligence (not as powerful as SourceGraph, but just goto definitions/references + browse file symbols) could be implemented. After finishing builds/tests the action might do something like Didn't open a new issue because of dependency on artifacts |
Are there any docs on built-in actions in 1.19.0? Even just a quick bullet point here in this thread? 🙏 |
Answering my own question, getting this up and running with Gitea v1.19.0 (from upstream Docker images) was pretty straight forward:
[actions]
ENABLED = true
$ git clone https://gitea.com/gitea/act_runner.git
$ cd act_runner
$ make build
$ ./act_runner register
# follow the instructions
$ ./act_runner daemon That's it! 🥳 Now just add workflows in |
Happy to continue beta testing this (I also run an older Drone CI setup too!) and provide feedback. One thing that springs to mind (which I'm hoping one of the developers can answer):
Basically, instead of having a static pool of runners (however I choose to run them), it would be nice to have a webhook (globally) that I can listen on and spawn a new runner on demand (say in a virtual machine or similar). Thanks! 🙏 |
Apparently in version 19.0.1 we should put something different in the
|
@aminify I think it's just:
https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions |
No, the cheatsheet is still true. |
All units configuration should use |
This would be nice! I've been tinkering with using it to deploy/restart my docker services. Would be nice if it could just do dynamic generation / access from outside for runner tokens. That way the container is more ephemeral. Also its probably been said before, but an environment variable for enabling actions would be nice, instead of having to update |
I have setup the runner and everything and I have a |
You need to install it or use a docker image runner that has it installed |
thanks @panekj |
Another missing part of Gitea's implementation of Github Actions is workflow commands in general, but most critically the |
Wait?! Why are you logging secrets in the first place? 🤔 |
I can confirm this. I use the 1password action to retrieve passwords. They are logged in all their beauty. Their code says |
There are Programs who print API Keys for debug reasons with no Way to disable it. It also possible, that this may be leaked in a error message when something crashes, so it's generally a good Idea to mask this, just in case. |
FWIW - Today I discovered gitlab can do this and it's all documented here: |
Those programs should be loaded up on a rocket and shot into sun! 😆 talk about security law practice 🤦♂️ |
I wonder how much more we want to abuse this one issue? |
A new documentation section for Gitea Actions. Some content comes from: - [Hacking on Gitea Actions](https://blog.gitea.io/2023/03/hacking-on-gitea-actions/) - The README of [act_runner](https://gitea.com/gitea/act_runner) - @ChristopherHX's excellent overview of the differences between Gitea Actions and GitHub Actions in [this comment](#13539 (comment)). --------- Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Internal CI/CD system
I propose to implement an internal CI/CD system that is compatible with Github workflows
yaml
syntax, actionyaml
syntax, and most action plugins. And this is in fact not only a CI/CD system, but you can also choose to not check out the code for some events for example, when an issue is posted, you want to reply to them, then you don't need to check out the code. You can just reply to that issue. So the sub-system name isbots
actions
, if you have a better name than that, please let me know.Pros
ubuntu-latest
is very big but Gitea now will usenode:16-buster
as the default image which is about 150MB and of course you could change it yourself.Cons
Reference documentation
At the moment, we lack documents, but if you want to know more details about what Github Actions looks like, please visit https://docs.github.com/en/actions.
Names chosen
Different from Github's related sub-system's name, we call the plugins
action
oractions
. Oneaction
in fact is a repository with a file namedaction.yml
in the root, the repository is hosted in any git service server which could begitea.com
, your self-hosted Gitea instance, and even github.com. There is a default configuration but we should also support absolute git URL as a plugin repository.Task summary
There are many things need to do
uses: https://github.com/peaceiris/actions-hugo@v2
https://gitea.com/gitea/act/pulls/14Javascript/Typescript
, but we need to support more programming languagesPython
https://gitea.com/gitea/act_runner/issues/44Golang
Rust
PHP
Although we will have an internal CI/CD system Gitea will still be open to integrating external systems and will provide more features to make the integration smooth. The below tasks do not belong to the internal CI/CD system but are very important for integrating the external CI/CD system
The text was updated successfully, but these errors were encountered: