[WORKFLOW] sync Forgejo with Gitea #51

Closed
opened 6 months ago by dachary · 31 comments
Owner

Tracking the weekly sync with Gitea main and Gitea stable releases, as described in the workflow.

The person assigned to the issue is responsible for carrying out the required actions and documenting any problem and their resolution in this issue.

Tracking the weekly sync with Gitea main and Gitea stable releases, [as described in the workflow](https://codeberg.org/forgejo/forgejo/src/branch/forgejo-development/CONTRIBUTING/WORKFLOW.md#development-workflow). The person assigned to the issue is responsible for carrying out the required actions and documenting any problem and their resolution in this issue.
dachary self-assigned this 6 months ago
dachary changed title from [WORKFLOW] sync Forgeo with Gitea to [WORKFLOW] sync Forgejo with Gitea 6 months ago
Poster
Owner

First rebase on top of Gitea main at eec1c71880

First rebase on top of Gitea main at https://codeberg.org/forgejo/forgejo/commit/eec1c718806797b21ba5f6c1ceddf711e9d4801a
dachary added the due date 2022-12-03 6 months ago
Poster
Owner

Gitea main

there has been 26 commits in Gitea since last week

Gitea v1.18

there has been 6 commits in Gitea since last week

### Gitea main there has been 26 commits in Gitea since last week * https://codeberg.org/forgejo/forgejo/src/branch/forgejo-ci at https://codeberg.org/forgejo/forgejo/commit/e0c205082d9f2ea1375131a1af4f6ee2b39d249a * upgrade to alpine 3.17 https://codeberg.org/forgejo/forgejo/commit/9a69ea5d2d5727fac527ae209b23296289ee6038 * https://codeberg.org/forgejo/forgejo/src/branch/forgejo-development && `git reset --hard https://codeberg.org/forgejo/forgejo/src/branch/forgejo-ci` and `git cherry-pick a99deecbcd4c4ec3eebf2560499f59dcab478b6b..a21a8d18631f6363dfd1188f68367a4ad56a42fd` (i.e. commits from the former forgejo-development branch) * merged in https://codeberg.org/forgejo/forgejo/src/branch/forgejo * https://codeberg.org/forgejo/forgejo/src/branch/forgejo-development * the other branches do not yet pass CI and are not merged ### Gitea v1.18 there has been 6 commits in Gitea since last week * https://codeberg.org/forgejo/forgejo/src/branch/v1.18/forgejo-ci & v1.18/forgejo-integration & v1.18/forgejo at fdb5b89b7f7533db6c9098f130f27e79edc8f7cd
dachary modified the due date from 2022-12-03 to 2022-12-10 6 months ago
Owner

@dachary it looks like a couple of commits were lost in this process, including 44903a5b8c and 4c98c3c324

Did you forget to pull before rebasing?

@dachary it looks like a couple of commits were lost in this process, including https://codeberg.org/forgejo/forgejo/commit/44903a5b8c2930acf377c5cf381e3e6e42f0a2d0 and https://codeberg.org/forgejo/forgejo/commit/4c98c3c32410bd0dc7042c74686dc138f1c4194d Did you forget to pull before rebasing?
Owner

@dachary it looks like a couple of commits were lost in this process, including 44903a5b8c and 4c98c3c324

Did you forget to pull before rebasing?

I've cherry-picked those two commits onto forgeo-development, I hope that's okay.

> @dachary it looks like a couple of commits were lost in this process, including https://codeberg.org/forgejo/forgejo/commit/44903a5b8c2930acf377c5cf381e3e6e42f0a2d0 and https://codeberg.org/forgejo/forgejo/commit/4c98c3c32410bd0dc7042c74686dc138f1c4194d > > Did you forget to pull before rebasing? I've cherry-picked those two commits onto `forgeo-development`, I hope that's okay.
Poster
Owner

@dachary it looks like a couple of commits were lost in this process, including 44903a5b8c and 4c98c3c324

Did you forget to pull before rebasing?

Apparently I did.

I've cherry-picked those two commits onto forgeo-development, I hope that's okay.

Absolutely, thank you for fixing my mistake!

> @dachary it looks like a couple of commits were lost in this process, including https://codeberg.org/forgejo/forgejo/commit/44903a5b8c2930acf377c5cf381e3e6e42f0a2d0 and https://codeberg.org/forgejo/forgejo/commit/4c98c3c32410bd0dc7042c74686dc138f1c4194d > > Did you forget to pull before rebasing? Apparently I did. > I've cherry-picked those two commits onto forgeo-development, I hope that's okay. Absolutely, thank you for fixing my mistake!
Poster
Owner

Archive

The previous branches are prefixed soft-fork/2022-12-10/*

Gitea main

there has been 20 commits in Gitea since last week

Gitea v1.18

there has been 9 commits in Gitea since last week

CI

The runs were done but all over the place because of #35

### Archive The previous branches are prefixed `soft-fork/2022-12-10/*` ### Gitea main there has been 20 commits in Gitea since last week ### Gitea v1.18 there has been 9 commits in Gitea since last week ### CI The runs were done but all over the place because of https://codeberg.org/forgejo/forgejo/issues/35
dachary modified the due date from 2022-12-10 to 2022-12-17 6 months ago
Poster
Owner

Archive

The previous branches are prefixed soft-fork/2022-12-17/*

PRs

#110 base moved to soft-fork/2022-12-17/forgejo-development

Gitea main & stable

push Gitea main, release/v1.18, release/v1.17 in forgejo

forgejo-ci

forgejo-development

forgejo

v1.18/forgejo-ci & v1.18/forgejo

  • cherry-pick commits from forgejo-ci and resolve conflict on Dockerfile because of the maintener name change that is close to the alpine version (3.17 in main, 3.16 in v1.18)
  • force push to v1.18/forgejo-ci
  • tag run https://forgejo-woodpecker.gna.org/dachary/forgejo/pipeline/120
  • force push v1.18/forgejo-ci to v1.18/forgejo since there is no difference at the moment
### Archive The previous branches are prefixed `soft-fork/2022-12-17/*` ### PRs https://codeberg.org/forgejo/forgejo/pulls/110 base moved to `soft-fork/2022-12-17/forgejo-development` ### Gitea main & stable push Gitea main, release/v1.18, release/v1.17 in forgejo ### forgejo-ci * rebase against gitea/main * squashed the woodpecker configuration into a single commit to facilitate backporting to `v1.18/forgejo-ci` * force push to forgejo-ci * ✅ branch run https://forgejo-woodpecker.gna.org/forgejo/forgejo/pipeline/32 ### forgejo-development * squashed all commits in four that (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` * ✅ branch run https://forgejo-woodpecker.gna.org/forgejo/forgejo/pipeline/36 ### forgejo * force push `forgejo-development` to `forgejo` * ✅ branch run https://forgejo-woodpecker.gna.org/forgejo/forgejo/pipeline/37 ### v1.18/forgejo-ci & v1.18/forgejo * cherry-pick commits from `forgejo-ci` and resolve conflict on Dockerfile because of the maintener name change that is close to the alpine version (3.17 in main, 3.16 in v1.18) * force push to v1.18/forgejo-ci * ✅ tag run https://forgejo-woodpecker.gna.org/dachary/forgejo/pipeline/120 * force push v1.18/forgejo-ci to v1.18/forgejo since there is no difference at the moment
dachary modified the due date from 2022-12-17 to 2022-12-24 5 months ago
Poster
Owner

Archive

The previous branches are prefixed soft-fork/2022-12-24/*

PRs

#148 base moved to soft-fork/2022-12-24/forgejo-development

Gitea main & stable

push Gitea main, release/v1.18, release/v1.17 in forgejo

forgejo-ci

forgejo-development

  • squashed all commits in four that (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README
  • cherry picked those commits on top of forgejo-ci
  • force push to forgejo-development

forgejo-branding

forgejo-privacy

forgejo-i18n

forgejo

v1.18/forgejo-ci

v1.18/forgejo-branding

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo

image

### Archive The previous branches are prefixed `soft-fork/2022-12-24/*` ### PRs https://codeberg.org/forgejo/forgejo/pulls/148 base moved to `soft-fork/2022-12-24/forgejo-development` ### Gitea main & stable push Gitea main, release/v1.18, release/v1.17 in forgejo ### forgejo-ci * rebase against gitea/main * squashed the woodpecker configuration into a single commit to facilitate backporting to `v1.18/forgejo-ci` * force push to forgejo-ci * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/60 * ✅ tag run https://ci.dachary.org/dachary/forgejo/pipeline/14 ### forgejo-development * squashed all commits in four that (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` ### forgejo-branding * cherry picked commits on top of `forgejo-development` * force push to `forgejo-branding` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/63 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/62 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * squash all commits updating `build/merge-forgejo-locales.go` * force push to `forgejo-i18n` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/64 ### forgejo * merge `forgejo-{privacy,i18n,branding}` into `forgejo` * force push to `forgejo` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/65 ### v1.18/forgejo-ci * cherry-pick commits from `forgejo-ci` and resolve conflict on Dockerfile because of the maintener name change that is close to the alpine version (3.17 in main, 3.16 in v1.18) * force push to v1.18/forgejo-ci * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/69 * ✅ tag run https://ci.dachary.org/dachary/forgejo/pipeline/15 ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-branding` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/70 ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-privacy` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/80 (transient failure https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/79 https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/76 https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/74) ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-i18n` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/71 ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/78 (transient failure: https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/77 https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/75 https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/73) * ✅ tag run https://ci.dachary.org/dachary/forgejo/pipeline/16 ![image](/attachments/7b5bb8ec-950c-42db-9016-df5ece5d4df5)
dachary modified the due date from 2022-12-24 to 2022-12-31 5 months ago
dachary modified the due date from 2022-12-31 to 2023-01-02 5 months ago
Poster
Owner

Shifting this to tomorrow because it feels like #188 should really be ready to make a more robust release cycle.

Shifting this to tomorrow because it feels like https://codeberg.org/forgejo/forgejo/pulls/188 should really be ready to make a more robust release cycle.
Poster
Owner

Shift this to tomorrow because #188 required more work than anticipated.

Shift this to tomorrow because #188 required more work than anticipated.
dachary modified the due date from 2023-01-02 to 2023-01-03 5 months ago
Poster
Owner

Archive

The previous branches are prefixed soft-fork/2023-01-03/*

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

forgejo-ci

forgejo-development

  • squashed all commits in four that (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README
  • cherry picked those commits on top of forgejo-ci
  • force push to forgejo-development

forgejo-branding

forgejo-privacy

forgejo-i18n

forgejo

v1.18/forgejo-ci

v1.18/forgejo-branding

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo

### Archive The previous branches are prefixed `soft-fork/2023-01-03/*` ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/198#issuecomment-756711 * https://codeberg.org/forgejo/forgejo/pulls/203#issuecomment-756714 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### forgejo-ci * rebase against gitea/main * squashed the woodpecker configuration into a single commit to facilitate backporting to `v1.18/forgejo-ci` * force push to forgejo-ci * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/216 ### forgejo-development * squashed all commits in four that (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` ### forgejo-branding * cherry picked commits on top of `forgejo-development` * force push to `forgejo-branding` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/217 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/218 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * force push to `forgejo-i18n` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/219 ### forgejo * merge `forgejo-{privacy,i18n,branding}` into `forgejo` * force push to `forgejo` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/220 ### v1.18/forgejo-ci * cherry-pick commits from `forgejo-ci` and resolve conflict on Dockerfile because of the maintener name change that is close to the alpine version (3.17 in main, 3.16 in v1.18) * force push to v1.18/forgejo-ci * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/224 ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-branding` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/232 (transient error https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/227) ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-privacy` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/231 (transient error https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/226) ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-i18n` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/230 (transient error https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/225) ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/228 * tag run v1.18.0-2 on forgejo-integration * ✅ container images https://ci.dachary.org/forgejo-integration/forgejo/pipeline/57 (stuck https://ci.dachary.org/forgejo-integration/forgejo/pipeline/56 https://ci.dachary.org/forgejo-integration/forgejo/pipeline/55) * ✅ binaries https://ci.dachary.org/forgejo-integration/forgejo/pipeline/58 * tag run v1.18.0-2 on forgejo/experimental * ✅ container images https://ci.dachary.org/forgejo/experimental/pipeline/7 * ✅ binaries https://ci.dachary.org/forgejo/experimental/pipeline/9 (transient error https://ci.dachary.org/forgejo/experimental/pipeline/8)
Owner

@dachary out of curiosity, how long does it take you each time to do the weekly rebase?

Would it be possible to automate most of this work, or is it quick enough not to be worthwhile?

@dachary out of curiosity, how long does it take you each time to do the weekly rebase? Would it be possible to automate most of this work, or is it quick enough not to be worthwhile?
Poster
Owner

It's taking me a lot of time for a lot of different reasons. The sync itself is around one hour of manual work total, which is not much.

But I spent dozens of hours working on the context to make that possible (the CI being the most time consuming) as well as the tiny details (method and rationale for archiving the branches under soft-fork/* for instance).

As you can see from the logs, last week rebase involved a lot of tag builds and this is no longer the case. Also this time around I worked on how to communicate the cherry-pick with people who have open pull requests: it went better than I expected but there were bumps.

I tend to manually do things and document them as much as humanly possible before writing tools, specially in the early days. Once the manual process repeats a few times and seems sound, I'll write tools to automate the most tedious / error prone parts.

My main concern is to figure out how comfortable people are working on top of feature branches that need rebasing. My hope is that it will feel like working on any other Free Software project most of the time. I think we are yet to discover friction points and it is possible that reducing/removing these friction points will require adopting a different rebasing workflow than what I'm currently doing. It will be easier to do that if there is no tooling at all. If there is tooling, there is also going to be some resistance to change because of the working committed to write and test these tools.

I'm rambling a little but hopefully you get why and how I'm approaching this 😄

It's taking me a lot of time for a lot of different reasons. The sync itself is around one hour of manual work total, which is not much. But I spent dozens of hours working on the context to make that possible (the CI being the most time consuming) as well as the tiny details (method and rationale for archiving the branches under soft-fork/* for instance). As you can see from the logs, last week rebase involved a lot of tag builds and this is no longer the case. Also this time around I worked on how to communicate the cherry-pick with people who have open pull requests: it went better than I expected but there were bumps. I tend to manually do things and document them as much as humanly possible before writing tools, specially in the early days. Once the manual process repeats a few times and seems sound, I'll write tools to automate the most tedious / error prone parts. My main concern is to figure out how comfortable people are working on top of feature branches that need rebasing. My hope is that it will feel like working on any other Free Software project most of the time. I think we are yet to discover friction points and it is possible that reducing/removing these friction points will require adopting a different rebasing workflow than what I'm currently doing. It will be easier to do that if there is no tooling at all. If there is tooling, there is also going to be some resistance to change because of the working committed to write and test these tools. I'm rambling a little but hopefully you get why and how I'm approaching this :smile:
Owner

Thanks for the detailed answer. It seems like more work than I would initially have assumed, but roughly what I had come to understand after seeing it done a few times.

I tend to manually do things and document them as much as humanly possible before writing tools, specially in the early days. Once the manual process repeats a few times and seems sound, I'll write tools to automate the most tedious / error prone parts.

Very wise, this makes a lot of sense.

this time around I worked on how to communicate the cherry-pick with people who have open pull requests: it went better than I expected but there were bumps.

Yes, I saw that. It's a pity we have to put that extra burden on contributors, but I don't have any better ideas. It would be great if we could clearly and simply document that workflow somewhere, to make it as easy as possible.

Similarly, we should document the easiest way for people to keep all their forgejo-* branches up to date after each rebase, since git pull doesn't work.

You suggested:

git reset --hard 7dd926454e # tip of forgejo-branding

I normally do this:

git update-ref refs/heads/forgejo-branding refs/remotes/origin/forgejo-branding

and the same for each forgejo-* branch. This has the advantage of not needing to check out each branch. I was actually thinking of writing a quick shell script to iterate over the branches doing it for me.
(I'm not a git expert so there may be a disadvantage to this technique that I'm not aware of.)

My main concern is to figure out how comfortable people are working on top of feature branches that need rebasing. My hope is that it will feel like working on any other Free Software project most of the time.

I think the problem is that effectively all PRs become stale after every rebase, and the process to refresh them (cherry-picking) is something most people are not familiar with. But I don't have a better solution, other than documenting it as simply as possible.

I'm rambling a little but hopefully you get why and how I'm approaching this 😄

Definitely, thanks!

Thanks for the detailed answer. It seems like more work than I would initially have assumed, but roughly what I had come to understand after seeing it done a few times. > I tend to manually do things and document them as much as humanly possible before writing tools, specially in the early days. Once the manual process repeats a few times and seems sound, I'll write tools to automate the most tedious / error prone parts. Very wise, this makes a lot of sense. > this time around I worked on how to communicate the cherry-pick with people who have open pull requests: it went better than I expected but there were bumps. Yes, I saw that. It's a pity we have to put that extra burden on contributors, but I don't have any better ideas. It would be great if we could clearly and simply document that workflow somewhere, to make it as easy as possible. Similarly, we should document the easiest way for people to keep all their `forgejo-*` branches up to date after each rebase, since `git pull` doesn't work. You suggested: ```sh git reset --hard 7dd926454e # tip of forgejo-branding ``` I normally do this: ```sh git update-ref refs/heads/forgejo-branding refs/remotes/origin/forgejo-branding ``` and the same for each `forgejo-*` branch. This has the advantage of not needing to check out each branch. I was actually thinking of writing a quick shell script to iterate over the branches doing it for me. (I'm not a git expert so there may be a disadvantage to this technique that I'm not aware of.) > My main concern is to figure out how comfortable people are working on top of feature branches that need rebasing. My hope is that it will feel like working on any other Free Software project most of the time. I think the problem is that effectively all PRs become stale after every rebase, and the process to refresh them (cherry-picking) is something most people are not familiar with. But I don't have a better solution, other than documenting it as simply as possible. > I'm rambling a little but hopefully you get why and how I'm approaching this 😄 Definitely, thanks!

Definitely, thanks!

I must second this thank you, your work in forgejo is fundamental and has given me a lot of knowledge and good practices.

>Definitely, thanks! I must second this thank you, your work in forgejo is fundamental and has given me a lot of knowledge and good practices.
dachary modified the due date from 2023-01-03 to 2023-01-07 5 months ago
dachary modified the due date from 2023-01-07 to 2023-01-10 5 months ago
Poster
Owner

Archive

The current branches are archived using main.sh archive_branches.
The branch archives from soft-fork/2022-12-10 and soft-fork/2022-12-17 are removed to not clutter the list of branches.

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

forgejo-ci

forgejo-development

  • squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE
  • cherry picked those commits on top of forgejo-ci
  • force push to forgejo-development

forgejo-branding

forgejo-privacy

forgejo-i18n

  • cherry picked commits on top of forgejo-development
  • squash updates to build/merge-forgejo-locales.go into a single commit
  • prefix all commit messages with [I18N]
  • move branding modification to routers/install/install.go out to forgejo-branding
  • force push to forgejo-i18n
  • : branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/269

forgejo

v1.18/forgejo-ci

v1.18/forgejo-development

v1.18/forgejo-branding

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo

### Archive The current branches are archived using [main.sh archive_branches](https://codeberg.org/forgejo-contrib/soft-fork-tools). The branch archives from `soft-fork/2022-12-10` and `soft-fork/2022-12-17` are removed to not clutter the list of branches. ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/198 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### forgejo-ci * rebase against gitea/main * squashed the woodpecker configuration into a single commit to facilitate backporting to `v1.18/forgejo-ci` * force push to forgejo-ci * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/260 ### forgejo-development * squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` ### forgejo-branding * cherry picked commits on top of `forgejo-development` * force push to `forgejo-branding` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/267 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * prefix all commit messages with [PRIVACY] * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/268 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * squash updates to build/merge-forgejo-locales.go into a single commit * prefix all commit messages with [I18N] * move branding modification to routers/install/install.go out to `forgejo-branding` * force push to `forgejo-i18n` * ✅: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/269 ### forgejo * merge `forgejo-{privacy,i18n,branding}` into `forgejo` * force push to `forgejo` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo (transient failure https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/272) ### v1.18/forgejo-ci * cherry-pick commits from `forgejo-ci` and resolve conflict on Dockerfile because of the maintener name change that is close to the alpine version (3.17 in main, 3.16 in v1.18) * force push to v1.18/forgejo-ci * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/266 ### v1.18/forgejo-development * cherry picked `forgejo-development` commits on top of `v1.18/forgejo-ci` * force push to `v1.18/forgejo-development` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/270 ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-branding` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/271 ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-privacy` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/274 ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-i18n` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/273 ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * ✅ branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/275 * tag run v1.18.0-2 on forgejo-integration * ✅ container images https://ci.dachary.org/forgejo-integration/forgejo/pipeline/60 * ✅ binaries https://ci.dachary.org/forgejo-integration/forgejo/pipeline/61 * tag run v1.18.0-2 on forgejo/experimental * ✅ container images https://ci.dachary.org/forgejo/experimental/pipeline/10 * ✅ binaries https://ci.dachary.org/forgejo/experimental/pipeline/11 * ✅ PR run on https://codeberg.org/Codeberg-Infrastructure/scripted-configuration/ with v1.18.0-2 https://woodpecker-local.forgejo.org/dachary/scripted-configuration/pipeline/44
Poster
Owner

@caesar with this rebase the forgejo-i18n feature branch had a some commits squashed which helps for maintenance. Instead of cherry-picking an ever growing list of commits, these are neatly organized chronological commits that tell a kind of story. Should a conflict occur, it will be easier to deal with.

I refrained from doing the same with the forgejo-branding branch since you're actively working on it and I don't know how much you rely on its full history. Would you like to do something similar?

@caesar with this rebase the `forgejo-i18n` feature branch had a some commits squashed which helps for maintenance. Instead of cherry-picking an ever growing list of commits, these are neatly organized chronological commits that tell a kind of story. Should a conflict occur, it will be easier to deal with. I refrained from doing the same with the `forgejo-branding` branch since you're actively working on it and I don't know how much you rely on its full history. Would you like to do something similar?
dachary modified the due date from 2023-01-10 to 2023-01-17 5 months ago
Owner

@caesar with this rebase the forgejo-i18n feature branch had a some commits squashed which helps for maintenance. Instead of cherry-picking an ever growing list of commits, these are neatly organized chronological commits that tell a kind of story. Should a conflict occur, it will be easier to deal with.

@dachary I can see the logic behind doing this, but I also worry about hiding authorship information: is it fair to contributors if we strip their attribution from the commit history (by squashing commits from multiple authors into one) for the sake of tidiness / an easier workflow? I don't know the answer, I can see arguments both ways; it just made me a bit uncomfortable.

Maybe we could at least add a Co-authored-by trailer to the commit message for each author whose commits are squashed into a single one?
GitHub displays the information from that commit trailer in the UI. I'm not sure if Forgejo does; if not, it should.

I refrained from doing the same with the forgejo-branding branch since you're actively working on it and I don't know how much you rely on its full history. Would you like to do something similar?

To be honest I'm not really actively working on it right now so it wouldn't be a problem, but thanks for thinking of me.
Since I've done a lot of the work in that branch though, I'm happy to be the one who goes through and squashes what makes sense.

What's the best way for me to do that while fitting in with your workflow? I guess i shouldn't force-push to that branch now you've already merged it into forgejo, or would it not be a problem?

> @caesar with this rebase the `forgejo-i18n` feature branch had a some commits squashed which helps for maintenance. Instead of cherry-picking an ever growing list of commits, these are neatly organized chronological commits that tell a kind of story. Should a conflict occur, it will be easier to deal with. @dachary I can see the logic behind doing this, but I also worry about hiding authorship information: is it fair to contributors if we strip their attribution from the commit history (by squashing commits from multiple authors into one) for the sake of tidiness / an easier workflow? I don't know the answer, I can see arguments both ways; it just made me a bit uncomfortable. Maybe we could at least add a `Co-authored-by` trailer to the commit message for each author whose commits are squashed into a single one? GitHub displays the information from that commit trailer in the UI. I'm not sure if Forgejo does; if not, it should. > I refrained from doing the same with the `forgejo-branding` branch since you're actively working on it and I don't know how much you rely on its full history. Would you like to do something similar? To be honest I'm not really actively working on it right now so it wouldn't be a problem, but thanks for thinking of me. Since I've done a lot of the work in that branch though, I'm happy to be the one who goes through and squashes what makes sense. What's the best way for me to do that while fitting in with your workflow? I guess i shouldn't force-push to that branch now you've already merged it into `forgejo`, or would it not be a problem?
Poster
Owner

@caesar with this rebase the forgejo-i18n feature branch had a some commits squashed which helps for maintenance. Instead of cherry-picking an ever growing list of commits, these are neatly organized chronological commits that tell a kind of story. Should a conflict occur, it will be easier to deal with.

@dachary I can see the logic behind doing this, but I also worry about hiding authorship information: is it fair to contributors if we strip their attribution from the commit history (by squashing commits from multiple authors into one) for the sake of tidiness / an easier workflow? I don't know the answer, I can see arguments both ways; it just made me a bit uncomfortable.

This is on of the reason for archiving the branches under soft-fork/YYYY-MM-DD/*. Another is forensic analysis if (I should write "when" because accidents happen) a commit gets lost or a regression is introduced in a rebase. It is vitally important to not loose any commit.

As the number of archive branches grow it will cause UI issues (clutter, slowness) and it is likely they will need to be moved to a forgejo-archive repository for safekeeping. But this is something that can be addressed when and if it becomes a problem.

Maybe we could at least add a Co-authored-by trailer to the commit message for each author whose commits are squashed into a single one?

I agree.

GitHub displays the information from that commit trailer in the UI. I'm not sure if Forgejo does; if not, it should.

I think it does something of the kind when a PR is merged, in the merge commit comment.

I refrained from doing the same with the forgejo-branding branch since you're actively working on it and I don't know how much you rely on its full history. Would you like to do something similar?

To be honest I'm not really actively working on it right now so it wouldn't be a problem, but thanks for thinking of me.
Since I've done a lot of the work in that branch though, I'm happy to be the one who goes through and squashes what makes sense.

Great! In your own time though, there is no pressure.

What's the best way for me to do that while fitting in with your workflow? I guess i shouldn't force-push to that branch now you've already merged it into forgejo, or would it not be a problem?

You can force push forgejo-branding and it will be merged into forgejo on the next rebase on top of Gitea. Your changes won't be in the forgejo branch in the meantime. When I rework the commit history of a feature branch I take a look at pending pull requests targeting it because they are going to be impacted.

> > @caesar with this rebase the `forgejo-i18n` feature branch had a some commits squashed which helps for maintenance. Instead of cherry-picking an ever growing list of commits, these are neatly organized chronological commits that tell a kind of story. Should a conflict occur, it will be easier to deal with. > > @dachary I can see the logic behind doing this, but I also worry about hiding authorship information: is it fair to contributors if we strip their attribution from the commit history (by squashing commits from multiple authors into one) for the sake of tidiness / an easier workflow? I don't know the answer, I can see arguments both ways; it just made me a bit uncomfortable. This is on of the reason for archiving the branches under `soft-fork/YYYY-MM-DD/*`. Another is forensic analysis if (I should write "when" because accidents happen) a commit gets lost or a regression is introduced in a rebase. It is vitally important to not loose any commit. As the number of archive branches grow it will cause UI issues (clutter, slowness) and it is likely they will need to be moved to a `forgejo-archive` repository for safekeeping. But this is something that can be addressed when and if it becomes a problem. > Maybe we could at least add a `Co-authored-by` trailer to the commit message for each author whose commits are squashed into a single one? I agree. > GitHub displays the information from that commit trailer in the UI. I'm not sure if Forgejo does; if not, it should. I think it does something of the kind when a PR is merged, in the merge commit comment. > > I refrained from doing the same with the `forgejo-branding` branch since you're actively working on it and I don't know how much you rely on its full history. Would you like to do something similar? > > To be honest I'm not really actively working on it right now so it wouldn't be a problem, but thanks for thinking of me. > Since I've done a lot of the work in that branch though, I'm happy to be the one who goes through and squashes what makes sense. Great! In your own time though, there is no pressure. > What's the best way for me to do that while fitting in with your workflow? I guess i shouldn't force-push to that branch now you've already merged it into `forgejo`, or would it not be a problem? You can force push `forgejo-branding` and it will be merged into `forgejo` on the next rebase on top of Gitea. Your changes won't be in the `forgejo` branch in the meantime. When I rework the commit history of a feature branch I take a look at pending pull requests targeting it because they are going to be impacted.
Owner

Perfect, thanks. I'll do it some time in the next few days.

Perfect, thanks. I'll do it some time in the next few days.
Poster
Owner

Archive

The current branches are archived using main.sh archive_branches.

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

forgejo-ci

forgejo-development

  • squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE
  • cherry picked those commits on top of forgejo-ci
  • force push to forgejo-development

forgejo-branding

forgejo-privacy

forgejo-i18n

forgejo

v1.18/forgejo-ci

v1.18/forgejo-development

v1.18/forgejo-branding

  • cherry picked forgejo-branding commits on top of v1.18/forgejo-development
  • conflict resolution:
    • AllowedHeaders: append([]string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"}, setting.CORSConfig.Headers...), was
    • AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},
  • conflict resolution: routers/web/web.go web.Bind was bindIgnErr
  • conflict resolution: services/webhook/webhook.go webhook_module was webhook_model
  • conflict resolution: web/repo/webhook.go webhook_module was webhook
  • force push to v1.18/forgejo-branding
  • branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/350

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo

### Archive The current branches are archived using [main.sh archive_branches](https://codeberg.org/forgejo-contrib/soft-fork-tools). ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/250 * https://codeberg.org/forgejo/forgejo/pulls/242 * https://codeberg.org/forgejo/forgejo/pulls/198 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### forgejo-ci * rebase against gitea/main * resolve conflict because of the addition of freebsd * force push to forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/320 ### forgejo-development * squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` ### forgejo-branding * cherry picked commits on top of `forgejo-development` * force push to `forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/321 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * prefix all commit messages with [PRIVACY] * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/322 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * squash updates to build/merge-forgejo-locales.go into a single commit * force push to `forgejo-i18n` * :white_check_mark:: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/323 ### forgejo * reset to forgejo/main * merge `forgejo-{privacy,i18n,branding}` into `forgejo` * force push to `forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/324 ### v1.18/forgejo-ci * cherry-pick the commits on top of the latest release/v1.18 * cherry-pick 40229a7dd8edc0f07fb1982c0912fdf4df083871 Skip GitHub migration tests if the API token is undefined (#21824) * force push to v1.18/forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/348 ### v1.18/forgejo-development * cherry picked `forgejo-development` commits on top of `v1.18/forgejo-ci` * solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted * force push to `v1.18/forgejo-development` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/349 ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-development` * conflict resolution: * `AllowedHeaders: append([]string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"}, setting.CORSConfig.Headers...),` was * `AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},` * conflict resolution: routers/web/web.go web.Bind was bindIgnErr * conflict resolution: services/webhook/webhook.go webhook_module was webhook_model * conflict resolution: web/repo/webhook.go webhook_module was webhook * force push to `v1.18/forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/350 ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-privacy` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/354 ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/329 ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/371 * tag run v1.18.1-0 on forgejo-integration * :white_check_mark: container images https://ci.dachary.org/forgejo-integration/forgejo/pipeline/72 * :white_check_mark: binaries https://ci.dachary.org/forgejo-integration/forgejo/pipeline/73 * tag run v1.18.1-0 on forgejo/experimental * :white_check_mark: container images https://ci.dachary.org/forgejo/experimental/pipeline/12 * :white_check_mark: binaries https://ci.dachary.org/forgejo/experimental/pipeline/12 * :white_check_mark: run on https://codeberg.org/dachary/scripted-configuration/ with v1.18.1-0 https://woodpecker-local.forgejo.org/dachary/scripted-configuration/pipeline/47
Poster
Owner

I won't work on tooling this time around because 1.18.1-0 should happen soon.

I won't work on tooling this time around because 1.18.1-0 should happen soon.

Thanks @dachary for this.
I have one question about conflicts: I understand that each conflict should be resolved at each branch for futures syncs in order to avoid conflict escalation. I mean, if a function change its name, or change the scope of a modified code, that modification should be updated to fit to the new upstream code to prevent future conflicts in this sync, I am right?
I am not shure if this is obvious or should be documented to avoid confusion.

Thanks @dachary for this. I have one question about conflicts: I understand that each conflict should be resolved at each branch for futures syncs in order to avoid conflict escalation. I mean, if a function change its name, or change the scope of a modified code, that modification should be updated to fit to the new upstream code to prevent future conflicts in this sync, I am right? I am not shure if this is obvious or should be documented to avoid confusion.
Poster
Owner

The rebase and the release are delayed until the Codeberg performance problems are resolved.

The rebase and the release are delayed until the Codeberg performance problems are resolved.
Poster
Owner

The rebase is complete and the release is available in experimental. Codeberg is not back to normal but using git only is a viable workaround for the release process.

The rebase is complete and the release is available in experimental. Codeberg is not back to normal but using git only is a viable workaround for the release process.
dachary modified the due date from 2023-01-17 to 2023-01-24 4 months ago
Poster
Owner

Archive

The current branches are archived using main.sh archive_branches.

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

forgejo-ci

forgejo-development

  • squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE
  • cherry picked those commits on top of forgejo-ci
  • force push to forgejo-development

forgejo-branding

forgejo-privacy

forgejo-i18n

forgejo

v1.18/forgejo-ci

v1.18/forgejo-development

  • cherry picked forgejo-development commits on top of v1.18/forgejo-ci
  • solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted
  • force push to v1.18/forgejo-development

v1.18/forgejo-branding

  • cherry picked forgejo-branding commits on top of v1.18/forgejo-development
  • conflict resolution [BRANDING] add X-Forgejo-* headers
    • AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},
  • conflict resolution [BRANDING] define the forgejo webhook type
    • routers/web/web.go web.Bind was bindIgnErr
    • services/webhook/webhook.go webhook_module was webhook_model
    • routers/web/repo/webhook.go s/webhook_module/webhook/
    • modules/webhook/type.go was in models/webhook/webhook.go
      // Types of webhooks
      const (
         FORGEJO    HookType = "forgejo"
         GITEA      HookType = "gitea"
      
  • force push to v1.18/forgejo-branding
  • branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/418

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo

### Archive The current branches are archived using [main.sh archive_branches](https://codeberg.org/forgejo-contrib/soft-fork-tools). ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/242 * https://codeberg.org/forgejo/forgejo/pulls/278 * https://codeberg.org/forgejo/forgejo/pulls/279 * https://codeberg.org/forgejo/forgejo/pulls/280 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### forgejo-ci * rebase against gitea/main * squash changes to .woodpecker/* * force push to forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/406 ### forgejo-development * squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` ### forgejo-branding * cherry picked commits on top of `forgejo-development` * [cleanup the commit history](https://codeberg.org/forgejo/forgejo/issues/282) * force push to `forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/417 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * prefix all commit messages with [PRIVACY] * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/410 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * squash updates to build/merge-forgejo-locales.go into a single commit * force push to `forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/411 ### forgejo * reset to forgejo/main * merge `forgejo-{privacy,i18n,branding}` into `forgejo` * force push to `forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/419 ### v1.18/forgejo-ci * cherry-pick the commits on top of the latest release/v1.18 * do not cherry pick the commit that removes unstable tests as it does not exist in v1.18 * cherry-pick 40229a7dd8edc0f07fb1982c0912fdf4df083871 Skip GitHub migration tests if the API token is undefined (#21824) * force push to v1.18/forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/414 ### v1.18/forgejo-development * cherry picked `forgejo-development` commits on top of `v1.18/forgejo-ci` * solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted * force push to `v1.18/forgejo-development` ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-development` * conflict resolution [BRANDING] add X-Forgejo-* headers * `AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},` * conflict resolution [BRANDING] define the forgejo webhook type * routers/web/web.go web.Bind was bindIgnErr * services/webhook/webhook.go webhook_module was webhook_model * routers/web/repo/webhook.go s/webhook_module/webhook/ * modules/webhook/type.go was in models/webhook/webhook.go ``` // Types of webhooks const ( FORGEJO HookType = "forgejo" GITEA HookType = "gitea" ``` * force push to `v1.18/forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/418 ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-privacy` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/415 ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/416 ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/420 * tag run v1.18.3-0 on forgejo-integration :white_check_mark: https://ci.dachary.org/forgejo-integration/forgejo/pipeline/83 * tag run v1.18.3-0 on forgejo/experimental :white_check_mark: https://ci.dachary.org/forgejo/experimental/pipeline/17 * :white_check_mark: run on https://codeberg.org/dachary/scripted-configuration/ with v1.18.3-0 https://ci.dachary.org/dachary/scripted-configuration/pipeline/124
dachary modified the due date from 2023-01-24 to 2023-01-27 4 months ago
dachary modified the due date from 2023-01-27 to 2023-01-28 4 months ago
Poster
Owner

Archive

The current branches are archived using main.sh archive_branches.

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

forgejo-ci

forgejo-development

  • squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE
  • cherry picked those commits on top of forgejo-ci
  • force push to forgejo-development

forgejo-branding

forgejo-privacy

forgejo-i18n

forgejo

v1.18/forgejo-ci

v1.18/forgejo-development

  • cherry picked forgejo-development commits on top of v1.18/forgejo-ci
  • solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted
  • force push to v1.18/forgejo-development

v1.18/forgejo-branding

  • cherry picked forgejo-branding commits on top of v1.18/forgejo-development
  • conflict resolution [BRANDING] Rebrand footer "powered by" links
    • trivial context change
  • conflict resolution [BRANDING] add X-Forgejo-* headers
    • AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},
  • conflict resolution [BRANDING] define the forgejo webhook type
    • routers/web/web.go web.Bind was bindIgnErr
    • services/webhook/webhook.go webhook_module was webhook_model
    • routers/web/repo/webhook.go s/webhook_module/webhook/
    • modules/webhook/type.go was in models/webhook/webhook.go
      // Types of webhooks
      const (
         FORGEJO    HookType = "forgejo"
         GITEA      HookType = "gitea"
      
  • force push to v1.18/forgejo-branding
  • branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/452

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo

### Archive The current branches are archived using [main.sh archive_branches](https://codeberg.org/forgejo-contrib/soft-fork-tools). ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/307 * https://codeberg.org/forgejo/forgejo/pulls/314 * https://codeberg.org/forgejo/forgejo/pulls/242 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### forgejo-ci * rebase against gitea/main * squash changes to .woodpecker/* * force push to forgejo-ci * :white_check_mark: branch run https://ci.dachary.org/forgejo/forgejo/pipeline/16/6 ### forgejo-development * squashed all commits into (i) delete old files, (ii) add CONTRIBUTING, (iii) add .gitea, (iv) add README, (v) update LICENSE * cherry picked those commits on top of `forgejo-ci` * force push to `forgejo-development` ### forgejo-branding * cherry picked commits on top of `forgejo-development` * [cleanup the commit history](https://codeberg.org/forgejo/forgejo/issues/282) * force push to `forgejo-branding` * :white_check_mark: branch run https://ci.dachary.org/forgejo/forgejo/pipeline/31 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * prefix all commit messages with [PRIVACY] * :white_check_mark: branch run https://ci.dachary.org/forgejo/forgejo/pipeline/27 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * squash updates to build/merge-forgejo-locales.go into a single commit * force push to `forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/442 ### forgejo * reset to forgejo/main * merge `forgejo-{privacy,i18n,branding}` into `forgejo` * force push to `forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/443 ### v1.18/forgejo-ci * cherry-pick the commits on top of the latest release/v1.18 * do not cherry pick the commit that removes unstable tests as it does not exist in v1.18 * cherry-pick 40229a7dd8edc0f07fb1982c0912fdf4df083871 Skip GitHub migration tests if the API token is undefined (#21824) * force push to v1.18/forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/449 ### v1.18/forgejo-development * cherry picked `forgejo-development` commits on top of `v1.18/forgejo-ci` * solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted * force push to `v1.18/forgejo-development` ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-development` * conflict resolution [BRANDING] Rebrand footer "powered by" links * trivial context change * conflict resolution [BRANDING] add X-Forgejo-* headers * `AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},` * conflict resolution [BRANDING] define the forgejo webhook type * routers/web/web.go web.Bind was bindIgnErr * services/webhook/webhook.go webhook_module was webhook_model * routers/web/repo/webhook.go s/webhook_module/webhook/ * modules/webhook/type.go was in models/webhook/webhook.go ``` // Types of webhooks const ( FORGEJO HookType = "forgejo" GITEA HookType = "gitea" ``` * force push to `v1.18/forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/452 ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-privacy` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/451 ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/450 ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/453 * tag run v1.18.3-1 on forgejo-integration :white_check_mark: https://ci.dachary.org/forgejo-integration/forgejo/pipeline/85 * tag run v1.18.3-1 on forgejo/experimental :white_check_mark: https://ci.dachary.org/forgejo/experimental/pipeline/19 * :white_check_mark: run on https://codeberg.org/dachary/scripted-configuration/ with v1.18.3-1 https://ci.dachary.org/dachary/scripted-configuration/pipeline/126
dachary modified the due date from 2023-01-28 to 2023-02-11 4 months ago
Poster
Owner

Archive

The current branches are archived using main.sh archive_branches.

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

test-env

forgejo-ci

forgejo-development

  • reset hard on top of forgejo-ci
  • cherry-pick all commits from the archived forgejo-ci branch
  • squash commits related to existing commits
  • add the [API] Forgejo API /api/forgejo/v1 to the commit history
  • force push to forgejo-development
  • branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/511

forgejo-branding

forgejo-privacy

forgejo-i18n

forgejo-a11y

forgejo

v1.18/forgejo-ci

v1.18/forgejo-development

  • cherry picked forgejo-development commits on top of v1.18/forgejo-ci
  • Revert "Use import of OCI structs (#22765) (#22805)" #334
  • solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted
  • conflict resolution [API] Forgejo API /api/forgejo/v1
    • Makefile trivial context conflict
    • routers/init.go trivial context conflict
    • go.mod, go.sum discard changes they are unecessary
  • force push to v1.18/forgejo-development
  • branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/525

v1.18/forgejo-branding

  • cherry picked forgejo-branding commits on top of v1.18/forgejo-development
  • conflict resolution [BRANDING] Rebrand footer "powered by" links
    • trivial context change
  • conflict resolution [BRANDING] add X-Forgejo-* headers (picked from previous archive branch)
    • AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},
  • conflict resolution [BRANDING] define the forgejo webhook type (picked from previous archive branch)
    • routers/web/web.go web.Bind was bindIgnErr
    • services/webhook/webhook.go webhook_module was webhook_model
    • routers/web/repo/webhook.go s/webhook_module/webhook/
    • modules/webhook/type.go was in models/webhook/webhook.go
      // Types of webhooks
      const (
         FORGEJO    HookType = "forgejo"
         GITEA      HookType = "gitea"
      
  • force push to v1.18/forgejo-branding
  • branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/534

v1.18/forgejo-privacy

v1.18/forgejo-i18n

v1.18/forgejo-a11y

v1.18/forgejo

### Archive The current branches are archived using [main.sh archive_branches](https://codeberg.org/forgejo-contrib/soft-fork-tools). ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/345 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### test-env * update https://codeberg.org/forgejo/test-env/ to match https://gitea.com/gitea/test-env * set the 1.18 branch to match main because v1.18 now is compatible with go 1.20 https://ci.dachary.org/forgejo/test-env/pipeline/5 ### forgejo-ci * rebase on top of gitea/main * squash changes to .woodpecker/* * force push to forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/508 ### forgejo-development * reset hard on top of `forgejo-ci` * cherry-pick all commits from the archived `forgejo-ci` branch * squash commits related to existing commits * add the [API] Forgejo API /api/forgejo/v1 to the commit history * force push to `forgejo-development` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/511 ### forgejo-branding * cherry picked commits on top of `forgejo-development` * force push to `forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/513 ### forgejo-privacy * cherry picked commits on top of `forgejo-development` * force push to `forgejo-privacy` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/514 ### forgejo-i18n * cherry picked commits on top of `forgejo-development` * force push to `forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/519 (transient failure https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/512) ### forgejo-a11y * cherry picked commits on top of `forgejo-development` * force push to `forgejo-a11y` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/515 ### forgejo * reset to forgejo/main * merge `forgejo-{privacy,i18n,branding,a11y}` into `forgejo` * force push to `forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/516 ### v1.18/forgejo-ci * cherry-pick the commits on top of the latest release/v1.18 * do not cherry pick the commit that removes unstable tests as it does not exist in v1.18 * cherry-pick ae6474ba9397d9d36d401a58988e4c1dbfce7146 [CI] use test-env:1.18 * cherry-pick 40229a7dd8edc0f07fb1982c0912fdf4df083871 Skip GitHub migration tests if the API token is undefined (#21824) * force push to v1.18/forgejo-ci * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/521 ### v1.18/forgejo-development * cherry picked `forgejo-development` commits on top of `v1.18/forgejo-ci` * Revert "Use import of OCI structs (#22765) (#22805)" https://codeberg.org/forgejo/forgejo/issues/334 * solve one conflict because CONTRIBUTING.md is not the same in v1.18 but it does not matter since it is deleted * conflict resolution [API] Forgejo API /api/forgejo/v1 * Makefile trivial context conflict * routers/init.go trivial context conflict * go.mod, go.sum discard changes they are unecessary * force push to `v1.18/forgejo-development` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/525 ### v1.18/forgejo-branding * cherry picked `forgejo-branding` commits on top of `v1.18/forgejo-development` * conflict resolution [BRANDING] Rebrand footer "powered by" links * trivial context change * conflict resolution [BRANDING] add X-Forgejo-* headers (picked from previous archive branch) * `AllowedHeaders: []string{"Authorization", "X-Gitea-OTP", "X-Forgejo-OTP"},` * conflict resolution [BRANDING] define the forgejo webhook type (picked from previous archive branch) * routers/web/web.go web.Bind was bindIgnErr * services/webhook/webhook.go webhook_module was webhook_model * routers/web/repo/webhook.go s/webhook_module/webhook/ * modules/webhook/type.go was in models/webhook/webhook.go ``` // Types of webhooks const ( FORGEJO HookType = "forgejo" GITEA HookType = "gitea" ``` * force push to `v1.18/forgejo-branding` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/534 ### v1.18/forgejo-privacy * cherry picked `forgejo-privacy` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-privacy` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/531 ### v1.18/forgejo-i18n * cherry picked `forgejo-i18n` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-i18n` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/533 ### v1.18/forgejo-a11y * cherry picked `forgejo-a11y` commits on top of `v1.18/forgejo-development` * force push to `v1.18/forgejo-a11y` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/532 ### v1.18/forgejo * merge `v1.18/forgejo-{privacy,i18n,branding,a11y}` into `v1.18/forgejo` * force push to `v1.18/forgejo` * :white_check_mark: branch run https://forgejo-ci.codeberg.org/forgejo/forgejo/pipeline/535 * tag run v1.18.3-2 on forgejo-integration :white_check_mark: https://ci.dachary.org/forgejo-integration/forgejo/pipeline/116 * tag run v1.18.3-2 on forgejo/experimental :white_check_mark: https://ci.dachary.org/forgejo/experimental/pipeline/25 * run on https://codeberg.org/dachary/scripted-configuration/ with container v1.18 https://ci.dachary.org/dachary/scripted-configuration/pipeline/128
dachary modified the due date from 2023-02-11 to 2023-02-18 4 months ago
dachary modified the due date from 2023-02-18 to 2023-02-19 3 months ago
dachary modified the due date from 2023-02-19 to 2023-02-20 3 months ago
Poster
Owner

I got busy with other things, therefore postponed one more day.

I got busy with other things, therefore postponed one more day.
Poster
Owner

Archive

The current branches are archived using main.sh archive_branches.

PRs

Provide detailed instructions to explain how to cherry pick

Gitea main & stable

push Gitea main, release/v1.18 in forgejo

test-env

Rebase milestone

Test run of release

### Archive The current branches are archived using [main.sh archive_branches](https://codeberg.org/forgejo-contrib/soft-fork-tools). ### PRs Provide detailed instructions to explain how to cherry pick * https://codeberg.org/forgejo/forgejo/pulls/376 ### Gitea main & stable push Gitea main, release/v1.18 in forgejo ### test-env * update https://codeberg.org/forgejo/test-env/ to match https://gitea.com/gitea/test-env * set the 1.18 branch to match main ### Rebase milestone * Created manually https://codeberg.org/forgejo/forgejo/milestone/3513 * All PRs in the milestone were prepared with [main.sh rebase_*](https://codeberg.org/forgejo-contrib/soft-fork-tools) & manual intervention * Each PR has comments to document the manual actions ### Test run of release * tag run v1.18.4-0 on forgejo-integration :clock1: ??? * tag run v1.18.4-0 on forgejo/experimental :clock1: ??? * run on https://codeberg.org/dachary/scripted-configuration/ with container v1.18 ???
Poster
Owner

Moved the notes to a dedicated issue in the milestone tracking the rebase. This concludes this long standing issue: further rebase will be a set of PR & issues grouped into a milestone.

Moved the notes to [a dedicated issue](https://codeberg.org/forgejo/forgejo/issues/395) in the milestone tracking the rebase. This concludes this long standing issue: further rebase will be a set of PR & issues grouped into a milestone.
dachary closed this issue 3 months ago
dachary removed the due date 2023-02-20 3 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: forgejo/forgejo#51
Loading…
There is no content yet.