Add gitea support

[ghost]

Took me a little longer, since i noticed that my initial idea would literally have required a full refactor, which was a little too large in scope. the above checklist is for keeping track of what will be added and this PR is here to track the progress and eventual questions.

closes #743

Plans

• Extending the configuration format and adding a [gitea] section
• Allowing to generate the configuration from known gitea remotes
• using gitea on the CreatePullRequest step
• using gitea on the Release step
• creating a new step SelectGiteaIssue
• adding a new forge concept to the documentation to link forge integrations together in a convenient place
• adding a new gitea section to the config file reference
• multi-forge support as mentioned in Add gitea support #743 (comment)

Testing

• PR generated by knope on a copy of one of the projects i work on. (fixes will be pushed in a bit)
  https://codeberg.org/FallenValkyrie/testing/pulls/5
• generated release
  https://codeberg.org/FallenValkyrie/testing/releases/tag/v0.3.0
• Adding tests in tests::gitea_release and tests::generate
• selecting gitea issues (token has already been deleted, so no need to censor it)
  
• Using the same testing repo to see if knope correctly asks for the GITEA_TOKEN
  

Notes

• Commits will be reorganized after review. This is simply because i don't feel like constantly reorganizing commits.
• The PR looks huge, but most of that is tests and test assets.
• Currently ureq (as far as i can tell) doesn't support sending multipart form data and the only library i could find, ureq_multipart, panics on IO errors and has messages in chinese (see in its own codebase). Together i find those unacceptable design choices. issue: Support Multipart Forms algesten/ureq#698

[netlify]

✅ Deploy Preview for knope canceled.

Name	Link
🔨 Latest commit	38383ae
🔍 Latest deploy log	https://app.netlify.com/sites/knope/deploys/65a1e1946ab4c90008e8e286

[ghost]

The clippy lint that is triggering makes no sense. The error is a copy of integrations::github::create_release::Error with some minor changes. So why does it trigger here, but not there? It also does not trigger locally. (answer: I was being dumb)

another one is the failing test. I do not know why it adds that unicode symbol there... i can't find that anywhere in the files.

---- version_go_mod stdout ----
thread 'version_go_mod' panicked at tests/gitea_release.rs:243:5:

---- expected: tests/gitea_release/version_go_mod/expected_go.mod
++++ actual:   In-memory
   1      - module codeberg.org/owner/repo // v1.1.0
        1 + module codeberg.org/owner/repo // v1.1.0∅

@dbanty would you know why this happens?

[ghost]

another one is the failing test. I do not know why it adds that unicode symbol there... i can't find that anywhere in the files.

---- version_go_mod stdout ----
thread 'version_go_mod' panicked at tests/gitea_release.rs:243:5:

---- expected: tests/gitea_release/version_go_mod/expected_go.mod
++++ actual:   In-memory
   1      - module codeberg.org/owner/repo // v1.1.0
        1 + module codeberg.org/owner/repo // v1.1.0∅

Okay, this one makes a lot of sense now. The in-memory value uses CRLF to mark the end of the line where the file uses LF.

[ghost]

Tested Release Workflow on https://codeberg.org/OpenThingies/openmood/releases

this is after fixing the releases url

[ghost]

https://codeberg.org/FallenValkyrie/testing/pulls/5

PR generated by knope on a copy of one of the projects i work on. (fixes will be pushed in a bit)

generated release:
https://codeberg.org/FallenValkyrie/testing/releases/tag/v0.3.0

[ghost]

preliminary code check

[ghost]

There we go, that should be it. The Commit history is nice and clean, Everything is implemented and i can't find any additional thing i could correct. That makes this PR ready for review. 🎉

[dbanty]

Thanks so much for this 🤩! I left some questions & suggestions in the review. Here are a few more that didn't belong to any particular file:

1. There are probably more places where "GitHub" is mentioned that can be cleaned up to more generic forge lingo. I'll take a scan around on a later day.
2. Semi-related, it seems like Gitea Actions is supposed to be compatible with GitHub Actions, does that mean that the release recipes preview release and workflow dispatch will work as is? If so, it'd be nice to update them to mention that Gitea can be used too.
3. Do you think it's worth noting the relationship between Codeberg, Forgejo, and Gitea in the docs anywhere? Or is that relationship well known by their users (I had to look it up 😁)
4. Can you add a test that verifies if multiple forges are configured they are all used?

Then, as a future follow-up, we probably should switch to a [[forges]] array to maintain the multi-forge capabilities but with more concise config. Historically I also include an auto-upgrade option with a deprecation so it's easy to update config. Adding the host option to GitHub isn't a bad idea either, for GitHub Enterprise.

[ghost]

Do you think it's worth noting the relationship between Codeberg, Forgejo, and Gitea in the docs anywhere? Or is that relationship well known by their users (I had to look it up 😁)

mmmh... from my experience the people that use codeberg/forgejo know they are based on and fully compatible with gitea. But i think your idea to make this even more generic in the future might actually allow us to not have to. I'd say we mention Forgejo in the forge concept as a supported forge to be more clear.

Semi-related, it seems like Gitea Actions is supposed to be compatible with GitHub Actions, does that mean that the release recipes preview release and workflow dispatch will work as is? If so, it'd be nice to update them to mention that Gitea can be used too.

mmh I'd say we test if we can get an equivalent configuration in gitea working. Tho hosting my own CI instance already stretches my money to its max, so rn i can't do it. Since I'm a proponent of testing/verifying before mentioning things in docs I'd leave that to be added a later day.

Can you add a test that verifies if multiple forges are configured they are all used?

Sure can do ^^

There are probably more places where "GitHub" is mentioned that can be cleaned up to more generic forge lingo. I'll take a scan around on a later day.

There were a few github specific examples that could stand cleaning. I've scanned the docs during my first try and it was quite a lot. Tho i would like to keep some of the GitHub specific stuff, since it mentions the CLI.

Then, as a future follow-up, we probably should switch to a [[forges]] array to maintain the multi-forge capabilities but with more concise config. Historically I also include an auto-upgrade option with a deprecation so it's easy to update config. Adding the host option to GitHub isn't a bad idea either, for GitHub Enterprise.

I wanted to try this from the start, but it changed so much of the codebase that it would've been a pain to review. I do support doing that tho ^^

[ghost]

I just noticed that you merged this into a local branch. Since I accepted the invite, i would have access to that branch. My question is: how would you like me to continue? Would you like me to switch to the local branch within the repo or do it on the fork I'm already working on and only do future contributions here?

[dbanty]

I didn’t intentionally merge it anywhere 🧐. Maybe something automatic that GitHub did? You’re more than welcome to work on a branch in here or on your fork, whatever is easiest!

[ghost]

Idk, see here:

Anyway, in that case I'll finish this PR on the fork, since that is simpler on both ends, and any future PRs will happen on a local branch ^^

[ghost]

There we go, that should (hopefully) fix the conflict. Tho when rebasing on main, i didn't get a conflict at all...

[dbanty]

Enforced that Gitea + assets aren't both declared and opened #779 to track adding in support (either manually with ureq or switching to something else)

[ghost]

Enforced that Gitea + assets aren't both declared

I could swear i did that... but it seems my brain never finished that thought...

[dbanty]

I think it's ready! Thanks again for pulling this together! I've added some follow-up issues in #779, #780, and #781 but I don't think this is worth holding up for any of those.