github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-14 03:46:23 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Docker Hub latest Tag Points to Release Candidate 1.18.0-rc0 #9746

New Issue
Closed
opened 2025-11-02 08:48:22 -06:00 by GiteaMirror · 21 comments
GiteaMirror commented 2025-11-02 08:48:22 -06:00
Owner
Copy Link

Originally created by @julmb on GitHub (Oct 27, 2022).

Description

Currently, the latest tag for gitea on docker hub [1] points to the same image as the 1.18.0-rc0 tag [2]. The documentation says that the latest tag should only point to stable releases.

This has happened before with 1.17.0 (#20058) and the configuration was apparently changed to prevent it from happening again, but now it has happened again.

[1] https://hub.docker.com/layers/gitea/gitea/latest/images/sha256-167f91cbf8f2d8e031d22c57928a157d4772aa378baa116a2f71f703b70b367f
[2] https://hub.docker.com/layers/gitea/gitea/1.18.0-rc0/images/sha256-167f91cbf8f2d8e031d22c57928a157d4772aa378baa116a2f71f703b70b367f

Gitea Version

1.18.0-rc0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Gitea from Docker Hub run via Docker Compose

Database

No response

Originally created by @julmb on GitHub (Oct 27, 2022). ### Description Currently, the `latest` tag for gitea on docker hub [1] points to the same image as the `1.18.0-rc0` tag [2]. The documentation says that the `latest` tag should only point to stable releases. This has happened before with 1.17.0 (#20058) and the configuration was apparently changed to prevent it from happening again, but now it has happened again. [1] https://hub.docker.com/layers/gitea/gitea/latest/images/sha256-167f91cbf8f2d8e031d22c57928a157d4772aa378baa116a2f71f703b70b367f [2] https://hub.docker.com/layers/gitea/gitea/1.18.0-rc0/images/sha256-167f91cbf8f2d8e031d22c57928a157d4772aa378baa116a2f71f703b70b367f ### Gitea Version 1.18.0-rc0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Gitea from Docker Hub run via Docker Compose ### Database _No response_
GiteaMirror added the type/bug label 2025-11-02 08:48:22 -06:00
GiteaMirror commented 2025-11-02 08:48:24 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Oct 27, 2022):

ref https://gitea.com/gitea/drone-docker/pulls/2

@6543 commented on GitHub (Oct 27, 2022): ref https://gitea.com/gitea/drone-docker/pulls/2
GiteaMirror commented 2025-11-02 08:48:24 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 27, 2022):

Since it has been tagged, I would like to stay latest == 1.18rc0, if we delete the tag, some users will encounter a downgrade. Our task is to push the 1.18.0 releasing ASAP.

@lunny commented on GitHub (Oct 27, 2022): Since it has been tagged, I would like to stay latest == 1.18rc0, if we delete the tag, some users will encounter a downgrade. Our task is to push the 1.18.0 releasing ASAP.
GiteaMirror commented 2025-11-02 08:48:24 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Oct 27, 2022):

same game as last time 😓

@6543 commented on GitHub (Oct 27, 2022): same game as last time :sweat:
GiteaMirror commented 2025-11-02 08:48:24 -06:00
Author
Owner
Copy Link

@MrHaroldA commented on GitHub (Nov 1, 2022):

Since it has been tagged, I would like to stay latest == 1.18rc0, if we delete the tag, some users will encounter a downgrade.

I actually encountered this, but a downgrade to 1.17 fails to start after an update to 1.18rc0, so I just went with 1.18rc0 after reading that it should be near a real release.

@MrHaroldA commented on GitHub (Nov 1, 2022): > Since it has been tagged, I would like to stay latest == 1.18rc0, if we delete the tag, some users will encounter a downgrade. I actually encountered this, but a downgrade to 1.17 fails to start after an update to 1.18rc0, so I just went with 1.18rc0 after reading that it should be near a real release.
GiteaMirror commented 2025-11-02 08:48:24 -06:00
Author
Owner
Copy Link

@ricariel commented on GitHub (Nov 2, 2022):

I would love to see a stable tag for this.

@ricariel commented on GitHub (Nov 2, 2022): I would love to see a stable tag for this.
GiteaMirror commented 2025-11-02 08:48:25 -06:00
Author
Owner
Copy Link

@xPuls3 commented on GitHub (Nov 20, 2022):

As the documentation says 'latest' is stable, it threw me off to see a release candidate version installed.
I would definitely like a 'stable' tag as mentioned above if this is going to continue happening.

@xPuls3 commented on GitHub (Nov 20, 2022): As the documentation says 'latest' is stable, it threw me off to see a release candidate version installed. I would definitely like a 'stable' tag as mentioned above if this is going to continue happening.
GiteaMirror commented 2025-11-02 08:48:25 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Nov 20, 2022):

As the documentation says 'latest' is stable, it threw me off to see a release candidate version installed. I would definitely like a 'stable' tag as mentioned above if this is going to continue happening.

Sorry, that's an accident event.

@lunny commented on GitHub (Nov 20, 2022): > As the documentation says 'latest' is stable, it threw me off to see a release candidate version installed. I would definitely like a 'stable' tag as mentioned above if this is going to continue happening. Sorry, that's an accident event.
GiteaMirror commented 2025-11-02 08:48:25 -06:00
Author
Owner
Copy Link

@f0086 commented on GitHub (Dec 13, 2022):

So, over a month later, the latest tag is still on the .rc1.
The 1.18.0 milestone seems almost complete for some time (https://github.com/go-gitea/gitea/milestone/120), when are you planning to push the 1.8.0 release?

@f0086 commented on GitHub (Dec 13, 2022): So, over a month later, the latest tag is still on the .rc1. The 1.18.0 milestone seems almost complete for some time (https://github.com/go-gitea/gitea/milestone/120), when are you planning to push the 1.8.0 release?
GiteaMirror commented 2025-11-02 08:48:26 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 14, 2022):

So, over a month later, the latest tag is still on the .rc1. The 1.18.0 milestone seems almost complete for some time (https://github.com/go-gitea/gitea/milestone/120), when are you planning to push the 1.8.0 release?

It should be soon and we fixed many bugs these days.

@lunny commented on GitHub (Dec 14, 2022): > So, over a month later, the latest tag is still on the .rc1. The 1.18.0 milestone seems almost complete for some time (https://github.com/go-gitea/gitea/milestone/120), when are you planning to push the 1.8.0 release? It should be soon and we fixed many bugs these days.
GiteaMirror commented 2025-11-02 08:48:26 -06:00
Author
Owner
Copy Link

@notDavid commented on GitHub (Dec 22, 2022):

So does this mean everyone on the latest tag (= 1.18.0+rc1) now doesn't have security fixes of 1.17.4 ?

https://github.com/go-gitea/gitea/releases/tag/v1.17.4

@notDavid commented on GitHub (Dec 22, 2022): So does this mean everyone on the `latest` tag (= `1.18.0+rc1`) now doesn't have security fixes of `1.17.4` ? https://github.com/go-gitea/gitea/releases/tag/v1.17.4
GiteaMirror commented 2025-11-02 08:48:26 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 22, 2022):

I think we do need to do another RC of 1.18 or release it. I'm not sure if we feel it's ready yet for release but it's getting there.

@zeripath commented on GitHub (Dec 22, 2022): I think we do need to do another RC of 1.18 or release it. I'm not sure if we feel it's ready yet for release but it's getting there.
GiteaMirror commented 2025-11-02 08:48:26 -06:00
Author
Owner
Copy Link

@KN4CK3R commented on GitHub (Dec 22, 2022):

1.18.0+rc1 includes everything until 24.11.2022, so the ghost fix you mentioned is included.

@KN4CK3R commented on GitHub (Dec 22, 2022): 1.18.0+rc1 includes everything until 24.11.2022, so the ghost fix you mentioned is included.
GiteaMirror commented 2025-11-02 08:48:27 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 22, 2022):

I think we do need to do another RC of 1.18 or release it. I'm not sure if we feel it's ready yet for release but it's getting there.

I agree to just release 1.18.0

@lunny commented on GitHub (Dec 22, 2022): > I think we do need to do another RC of 1.18 or release it. I'm not sure if we feel it's ready yet for release but it's getting there. I agree to just release 1.18.0
GiteaMirror commented 2025-11-02 08:48:27 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Dec 29, 2022):

we should not messup at next rc ... (1.19.0-rcX)

@6543 commented on GitHub (Dec 29, 2022): we should not messup at next rc ... (1.19.0-rcX)
GiteaMirror commented 2025-11-02 08:48:27 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 29, 2022):

I'm not sure it's really a mess-up. I know that people don't like this but we need to get people to test RCs.

@zeripath commented on GitHub (Dec 29, 2022): I'm not sure it's really a mess-up. I know that people don't like this but we need to get people to test RCs.
GiteaMirror commented 2025-11-02 08:48:27 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Dec 29, 2022):

Only problem: We declare latest to be the latest stable version. rcs are (by definition) not stable.
If we change that, I'm also fine with it.

@delvh commented on GitHub (Dec 29, 2022): Only problem: We declare `latest` to be `the latest stable version`. `rc`s are (by definition) not stable. If we change that, I'm also fine with it.
GiteaMirror commented 2025-11-02 08:48:27 -06:00
Author
Owner
Copy Link

@notDavid commented on GitHub (Dec 29, 2022):

So i'm pulling gitea/gitea:latest, but i'm receiving nothing. I'm running 1.18.0+rc1 instead of v1.18.0.

Is this as expected since v1.18.0 was just released?

EDIT: working now...👍🏼

@notDavid commented on GitHub (Dec 29, 2022): So i'm pulling `gitea/gitea:latest`, but i'm receiving nothing. I'm running `1.18.0+rc1` instead of `v1.18.0`. Is this as expected since `v1.18.0` was just released? EDIT: working now...👍🏼
GiteaMirror commented 2025-11-02 08:48:28 -06:00
Author
Owner
Copy Link

@gapodo commented on GitHub (Dec 29, 2022):

EDIT: just to clarify, as I was made aware, that I may have struck too harsh of a tone in this reply.

While I stand by this being problematic, esp. with the "maybe this was intended", this was my opinion, that was somewhat agitated / angry, as I wrote this reply after having had 3 full days of (unplanned, recovery) work at my day job, because another project had made pretty much that exact mistake. Please rest assured, that this was my personal opinion written down in a bad moment and missing the correct tone and neither based on nor supported by communities I am a part of.

The text below was not altered, I did it, it was said, so I'll just add this clarification / context as a note and also to own the mistake I made.

I'm not sure it's really a mess-up. I know that people don't like this but we need to get people to test RCs.

This is a big fat mess-up since latest was declared as the "stable" tag, anything other than a stable therefore is a mess-up.

Also if you want people to test, sneaking them an rc into their setup is a really messed up strategy and IMHO should be considered malicious behavior!

I agree that testing is necessary, but not this way. I get that most do not want to test RCs, I'm usually not keen on it either, as my setup is there to support my other tasks, not to be my task (as in testing, fixing, or desaster recovery), but forcing it on people isn't the way to do it.

If there is something people are waiting for, they will test it (at least if they have the time/resources/need), if existing things break, that's what tests are for... If it only happens under high load, high connection count,... (at scale) users testing RCs likely won't help, as those who are running at such scales usually pin their instances to the sha-digest and run pre-testing on different instances (usually at lower scale as simulating tons of users osn't the simplest rhing to do.

@gapodo commented on GitHub (Dec 29, 2022): EDIT: just to clarify, as I was made aware, that I may have struck too harsh of a tone in this reply. While I stand by this being problematic, esp. with the "maybe this was intended", this was **my** opinion, that was somewhat agitated / angry, as I wrote this reply after having had 3 full days of (unplanned, recovery) work at my day job, because another project had made pretty much that exact mistake. Please rest assured, that this was **my personal opinion** written down in a bad moment and missing the correct tone and neither based on nor supported by communities I am a part of. The text below was not altered, I did it, it was said, so I'll just add this clarification / context as a note and also to own the mistake I made. ------ > I'm not sure it's really a mess-up. I know that people don't like this but we need to get people to test RCs. This is a big fat mess-up since latest was declared as the "stable" tag, anything other than a stable therefore is a mess-up. Also if you want people to test, sneaking them an rc into their setup is a really messed up strategy and IMHO should be considered malicious behavior! I agree that testing is necessary, but not this way. I get that most do not want to test RCs, I'm usually not keen on it either, as my setup is there to support my other tasks, not to be my task (as in testing, fixing, or desaster recovery), but forcing it on people isn't the way to do it. If there is something people are waiting for, they will test it (at least if they have the time/resources/need), if existing things break, that's what tests are for... If it only happens under high load, high connection count,... (at scale) users testing RCs likely won't help, as those who are running at such scales usually pin their instances to the sha-digest and run pre-testing on different instances (usually at lower scale as simulating tons of users osn't the simplest rhing to do.
GiteaMirror commented 2025-11-02 08:48:28 -06:00
Author
Owner
Copy Link

@jolheiser commented on GitHub (Dec 29, 2022):

I also agree that latest should not include RCs. While I love the idea of getting them tested, latest should probably be reserved for stable.

If not, some option that does only include stable should be provided.
Alternatively, latest can be stable and another label can be used for pre-releases.

Apologies, I know we've discussed this before, but a cursory search doesn't bring it up on GH.

@jolheiser commented on GitHub (Dec 29, 2022): I also agree that `latest` should not include RCs. While I love the idea of getting them tested, `latest` should probably be reserved for stable. If not, some option that _does_ only include stable should be provided. Alternatively, `latest` can be stable and another label can be used for pre-releases. Apologies, I know we've discussed this before, but a cursory search doesn't bring it up on GH.
GiteaMirror commented 2025-11-02 08:48:28 -06:00
Author
Owner
Copy Link

@gapodo commented on GitHub (Dec 30, 2022):

@zeripath and everyone interested, I've added an edit to my message, as I have missed the tone. Sorry for screwing up that reply.

@gapodo commented on GitHub (Dec 30, 2022): @zeripath and everyone interested, I've added an edit to my message, as I have missed the tone. Sorry for screwing up that reply.
GiteaMirror commented 2025-11-02 08:48:29 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 30, 2022):

Since 1.18.0 released, I think we can close this one.

@lunny commented on GitHub (Dec 30, 2022): Since 1.18.0 released, I think we can close this one.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#9746
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?