Skip to content

Sync releases table with tags on push and for mirrors - #2459

Merged
lunny merged 7 commits into
go-gitea:masterfrom
lafriks-fork:sync_releases_tags
Sep 20, 2017
Merged

Sync releases table with tags on push and for mirrors#2459
lunny merged 7 commits into
go-gitea:masterfrom
lafriks-fork:sync_releases_tags

Conversation

@lafriks

@lafriks lafriks commented Sep 4, 2017

Copy link
Copy Markdown
Member

Fixes #2154

Not fully tested but ready for review

@lafriks lafriks added the issue/regression Indicates a previously functioning feature or behavior that has broken or regressed after a change label Sep 4, 2017
@lafriks lafriks added this to the 1.x.x milestone Sep 4, 2017
@lafriks lafriks modified the milestones: 1.3.0, 1.x.x Sep 4, 2017
Comment thread models/release.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we use a map[string]struct{} instead? It will be more efficient to check if tags have been checked below with a map.

Comment thread routers/api/v1/repo/release.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo?

@lafriks lafriks Sep 4, 2017

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is typo than it was also previously as I kept previous behaviour, it was returning status 409 when release already existed

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is not a typo:

ctx.Status(409)

Comment thread models/migrations/v39.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why update all are false ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default, probably not needed

Comment thread models/migrations/v39.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

offset += len(repos)

Comment thread models/release.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update after delete?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

forgot to remove update, good catch, thx

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually it is just in diff looks like this, if you look at the full file code there is no update before delete, update is from other function :)

@bkcsoft

bkcsoft commented Sep 4, 2017

Copy link
Copy Markdown
Contributor

So, why do we need to do this? Tags and Releases are not the same thing, they should not be treated as the same thing... If we need this list it should be fetched from the GitRepo directly 🤔

@tboerger tboerger added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Sep 4, 2017
@lafriks

lafriks commented Sep 4, 2017

Copy link
Copy Markdown
Member Author

@bkcsoft this is only way to efficiently implement release page paging and to have release page match github behavior. Releases are actually just extenended tags so can say they are quite the same

@lunny

lunny commented Sep 4, 2017

Copy link
Copy Markdown
Member

@lafriks I think maybe @bkcsoft is right. Since user will input username and password, we can retrieves release information via github API and inserted to gitea.( maybe an checkbox option: sync releases ). And this sync function also could be a button on tags UI to publish all the tags.

@lafriks

lafriks commented Sep 4, 2017

Copy link
Copy Markdown
Member Author

@bkcsoft @lunny it's not about just migration from github it's about displaying tags that are not linked to releases in release page like github is doing:

image

And it does not matter if repository is migrated or tags are created from git client. Not everyone wants or need to create releases for each tag but it is useful when creating tag to see kind of release list and only if needed create release with additional info and attachments. This is especially important for mirrored repositories and they can also be mirrored from github/gitlab etc

@lafriks

lafriks commented Sep 4, 2017

Copy link
Copy Markdown
Member Author

And also this was the functionality gitea had before release page was rewritten to show only data from database (I'm not against it)

@lunny

lunny commented Sep 5, 2017

Copy link
Copy Markdown
Member

@lafriks OK. I see.

@lunny

lunny commented Sep 5, 2017

Copy link
Copy Markdown
Member

LGTM

@tboerger tboerger added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Sep 5, 2017
@bkcsoft

bkcsoft commented Sep 5, 2017

Copy link
Copy Markdown
Contributor

we can retrieves release information via github API

@lunny I thought that any non-repo migration/sync would be left to third-party tools?

@lafriks

lafriks commented Sep 5, 2017

Copy link
Copy Markdown
Member Author

@bkcsoft but this PR is not related to it in any way but otherwise I agree 3rd-party sync/migration should be external tool

Comment thread models/release.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be "is_tag"?

Comment thread routers/api/v1/repo/release.go Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused here. If we are creating a release, why do we expect there to already be a release with the name form.TagName?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because release table does now contains also tags that are not full releases with attachments etc and when creating release it is needed to update release table flag (is_tag to false) and adding additional release information to that row

@bkcsoft

bkcsoft commented Sep 7, 2017

Copy link
Copy Markdown
Contributor

@lafriks Mainly just thinking out loud 🙂

@lafriks

lafriks commented Sep 8, 2017

Copy link
Copy Markdown
Member Author

@ethantkoenig fixed and also refactored code to minimize chance of possible race conditions

@lunny

lunny commented Sep 13, 2017

Copy link
Copy Markdown
Member

@lafriks and this one.

Minimize posibility of race conditions
@codecov-io

codecov-io commented Sep 16, 2017

Copy link
Copy Markdown

Codecov Report

Merging #2459 into master will decrease coverage by 0.22%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2459      +/-   ##
==========================================
- Coverage   27.21%   26.99%   -0.23%     
==========================================
  Files          85       85              
  Lines       16955    17097     +142     
==========================================
  Hits         4615     4615              
- Misses      11665    11807     +142     
  Partials      675      675
Impacted Files Coverage Δ
models/repo_mirror.go 0.61% <0%> (-0.04%) ⬇️
models/update.go 10.69% <0%> (-8.18%) ⬇️
models/repo.go 13.5% <0%> (-0.03%) ⬇️
models/release.go 0% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8b6236d...3927a9a. Read the comment docs.

@daviian daviian mentioned this pull request Sep 17, 2017
@lafriks

lafriks commented Sep 17, 2017

Copy link
Copy Markdown
Member Author

@lunny I think I found bug but have to still reproduce that, do not merge yet. Would be great if someone could test it on his dev environment

Comment thread models/release.go Outdated
existingRelTags := make(map[string]struct{})
opts := FindReleasesOptions{IncludeDrafts: true, IncludeTags: true}
page := 0
for {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: for page := 1; ; page++ {

@lafriks

lafriks commented Sep 17, 2017

Copy link
Copy Markdown
Member Author

@ethantkoenig fixed your suggestion
@lunny I think I fixed the bug but would appreciate if someone could test it more. At least for me it seems to work correctly now

@daviian

daviian commented Sep 17, 2017

Copy link
Copy Markdown
Member

@lafriks Found two issues.

  1. git treats tags case sensitive, therefore using toLowerCase could drop a tag
  2. if a tag is removed and added on a new commit sync doesn't update tag reference

But maybe there are more.

@daviian

daviian commented Sep 18, 2017

Copy link
Copy Markdown
Member

@lafriks Ok, I have finished my examination. Last commit definitely fixes bugs regarding release creation.
So above mentioned issues are still a problem.

As toLowerCase isn't an issue created with this PR it should be addressed separately.
But IMO tag reference update should be fixed before merging.

@ethantkoenig

ethantkoenig commented Sep 20, 2017

Copy link
Copy Markdown
Member

@lafriks I believe I found a bug. Never mind, was running an old version.

Steps to reproduce:

  1. Create a mirror repository of a Github repo with releases (for example, I used https://github.com/ethantkoenig/run_lambda)
  2. Make the repository a regular, non-mirror repository
  3. Clone the repo, and try deleting a tag (e.g. git push origin :v1.0.4)
  4. The release count remains unchanged, and the deleted tag still shows up in the list of release. When you try to view the deleted tag, you get a 404.

@ethantkoenig ethantkoenig left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind

@ethantkoenig

Copy link
Copy Markdown
Member

LGTM

@ethantkoenig

Copy link
Copy Markdown
Member

Make L-G-T-M work

@tboerger tboerger added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Sep 20, 2017
@lunny

lunny commented Sep 20, 2017

Copy link
Copy Markdown
Member

I made a mistake. @lafriks

@lunny
lunny merged commit 7a02978 into go-gitea:master Sep 20, 2017
@lafriks lafriks added the backport/done All backports for this PR have been created label Sep 20, 2017
lafriks added a commit to lafriks-fork/gitea that referenced this pull request Sep 20, 2017
* Sync releases table with tags on push and for mirrors

* Code style fixes

* Fix api to return only releases

* Optimize release creation and update
Minimize posibility of race conditions

* Fix release lower tag name updating

* handle tag reference update by addionally comparing commit id
lafriks added a commit that referenced this pull request Sep 20, 2017
* Sync releases table with tags on push and for mirrors

* Code style fixes

* Fix api to return only releases

* Optimize release creation and update
Minimize posibility of race conditions

* Fix release lower tag name updating

* handle tag reference update by addionally comparing commit id
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

backport/done All backports for this PR have been created issue/regression Indicates a previously functioning feature or behavior that has broken or regressed after a change lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Releases didn't display

7 participants