A new git-based development environment

[plusmid]

Hi @Itms, thank you for your effort to migrate to Git(ea).

I had a discussion on Mastodon about the switch and wanted to bring Forgejo to your attention. It's a fork of Gitea maintained by a non-profit rather than a for-profit corporation.

Switching over should be pretty easy as both projects are still very close. Maybe it's work a try.

Cheers, plusmid

Edited April 26 by plusmid

[Itms]

Hello @plusmid! I know about Forgejo. It's a great project and you're right to promote it.

Basically we want to use and support open-source software, but we'd also like to use widely-used, even if it's commercial, software in order to save energy in maintaining our tools. A lot of members of the community have been advocating for using Github, which everyone uses, and which is "too big to fail". Obviously we're reluctant to use Github/Microsoft closed software, but maybe we'll end up there anyway if it proves too difficult to self-host a forge. Gitlab is too heavy for us to self-host, Gitlab.com is another alternative possibility for the future.

I think Gitea is a very good middle-ground, both open-source, self-hosted and Github-like. It has official maintained support from the Jenkins developers (we use that for CI/CD). We're very happy to know that there is a non-profit alternative in case the Gitea firm starts doing shady stuff, but for now, the only thing we want from upstream is stability and ease-of-use. Forgejo is simply not big enough yet, to put it bluntly.

[plusmid]

A valid concern. I hope Forgejo will grow big enough to one day host 0ad. Thank you for your effort!

[BOB13671]

@ItmsAs someone who is interested in seeing the newest changes and just went through the arduous process of compiling the game from source, a nightly build sounds really cool.

 

Sadly, despite following the nightly build guide, I encountered an issue with TortoiseSVN failing to recognize  https://svn.itms.ovh/nightly-build/trunk. I'm wondering if this may be due to nightly builds not being implemented yet or if the svn link is not working as intended?

 

Edited April 28 by BOB13671

[Stan`]

If you're using tortoise SVN that means you're on Windows right ? Then if you use the current SVN repo you'll get autobuilds

And for linux once the deps are installed you can use a simple shell script to build everything.

https://code.wildfiregames.com/P241

[BOB13671]

The problem I was facing was following the guide for the nightly build (link), and the url for it does not exist. I tried this both on tortoiseGit and the linux terminal.

Example:

~$ svn checkout https://svn.itms.ovh/nightly-build/trunk
svn: E170000: URL 'https://svn.itms.ovh/nightly-build/trunk' doesn't exist

In other news I downloaded the code from the svn repo https://svn.wildfiregames.com/public/ps/trunk/ , and ran the bash script you provided, which it made it extremely easy to get the game running. Thank You!

[Norse_Harold]

I'd like to use my Gitea account to help identify issues with the new system, so please send the password.

What's being used for CI/CD, still Jenkins, or something else? Where in the web-based interface is the CI/CD system? I particularly want to see whether warnings from source/tools/entity/checkrefs.py are being passed to developers effectively, as it's relevant to the changes to build/jenkins/pipelines/docker-differential.Jenkinsfile in D5266.

[Stan`]

2 hours ago, Norse_Harold said:

I'd like to use my Gitea account to help identify issues with the new system, so please send the password.

What's being used for CI/CD, still Jenkins, or something else? Where in the web-based interface is the CI/CD system? I particularly want to see whether warnings from source/tools/entity/checkrefs.py are being passed to developers effectively, as it's relevant to the changes to build/jenkins/pipelines/docker-differential.Jenkinsfile in D5266.

Currently the CI/CD is not implemented, but yeah we'll probably use Jenkins. (There is new stuff like https://www.drone.io/ but everything is we currently have is for jenkins)

For security reasons, I don't think we should run the CI with the Jenkinsfile on the branches (malicious actors might do bad things) If you want to test a new CI script you need access to the Jenkins instance or talk to someone who does.

Regarding linting, it would be indeed interesting to have some better linting that what's currently done, where you have to check the linting on Jenkins. I've redirected error output to the correct stream, so you can technically get errors by filtering output 2. Currently IIRC the linting failing is not breaking the pipeline.

Regarding that change, I'm a bit sad it went from -tax to -actx (cause tax is fun and so is tau (unused), but the rest looks okay)

[Itms]

On 28/04/2024 at 2:44 AM, BOB13671 said:

Sadly, despite following the nightly build guide, I encountered an issue with TortoiseSVN failing to recognize  https://svn.itms.ovh/nightly-build/trunk. I'm wondering if this may be due to nightly builds not being implemented yet or if the svn link is not working as intended?

Not implemented yet, but close.

19 hours ago, Norse_Harold said:

I'd like to use my Gitea account to help identify issues with the new system, so please send the password.

Sent.

19 hours ago, Norse_Harold said:

What's being used for CI/CD, still Jenkins, or something else? Where in the web-based interface is the CI/CD system? I particularly want to see whether warnings from source/tools/entity/checkrefs.py are being passed to developers effectively

I'm almost ready to start CI (hopefully) and I'll use the checkrefs script as my main test avenue. It will allow me to check that Git LFS interacts correctly with the CI.

19 hours ago, Norse_Harold said:

as it's relevant to the changes to build/jenkins/pipelines/docker-differential.Jenkinsfile in D5266.

Once I have set things up, I will be very interested in having those changes in a pull request on gitea.

17 hours ago, Stan` said:

For security reasons, I don't think we should run the CI with the Jenkinsfile on the branches (malicious actors might do bad things) If you want to test a new CI script you need access to the Jenkins instance or talk to someone who does.

This is automatically covered by the Gitea Jenkins plugin. Jenkins uses the Jenkinsfile from the upstream branch when the pull request author is not a recognized contributor. If it works as advertised, this will remove the need to have access to the Jenkins instance.

[Stan`]

2 hours ago, Itms said:

This is automatically covered by the Gitea Jenkins plugin. Jenkins uses the Jenkinsfile from the upstream branch when the pull request author is not a recognized contributor. If it works as advertised, this will remove the need to have access to the Jenkins instance.

Neat!

[ShadowOfHassen]

Any update on this? I know people are busy with their own life, but I'm excited!

[Stan`]

5 minutes ago, ShadowOfHassen said:

Any update on this? I know people are busy with their own life, but I'm excited!

A presentation was given at a small french conference back in May, and work should resume during the summer

Work has been done on the documentation that can be checked there.

 

[Itms]

Hello folks! I have been hard at work on this, and things are starting to look usable.

Here is a (probably incomplete) changelog:

• The CI works! It is still a bit raw and I deactivated it to save space on Jenkins, but I am now working on improving it. It is the last big chunk of work I have to perform, and then we will be ready to migrate.
• The nightly build now exists! Get it via SVN at https://svn.itms.ovh/nightly-build/trunk. It is generated from a month ago but I'll update it through Jenkins in the upcoming days.
• All the documentation was updated and improved during the JDLL event in May where I presented the project and received some feedback. I also improved the Privacy Policy based on feedback. Please head over to the wiki especially BuildAndDeploymentEnvironment.

I need help! The glorious FAQ has been defaced by the conversion to Gitea, which uses Github-flavored Markdown. Is anyone interested in working on manually restoring the appearance of the FAQ, adapting it to its new home on Gitea? Please let me know if you wish to help. Basically it would be necessary to 1) cleanup the structure of the page, fix the tables, the raw HTML and hard links and 2) improve the appearance just like it was done on Trac, but using Markdown features instead of Trac features.

• The git repository now has a script for getting translations straight from the nightly build (the same will be done for Vulkan shaders)
• Links to changesets in the format [25001] on Trac are correctly converted to 04ec75ed7e on Gitea (and I fixed the commit text in that specific revision)
• Important Trac keywords (regression, pathfinding, design, ...) now have a Gitea label, but I can't easily automatically convert keywords to labels, so I will add the labels manually after the migration.

Thanks in advance for your feedback!