text:
How do you configure HTTPS with Docker and nginx reverse-proxy?

Hello, I would like to use Gitea with Docker and HTTPS (use nginx as reverse proxy).
This is (part of) my app.ini:
[server]
APP_DATA_PATH    = /data/gitea
DOMAIN           = localhost
SSH_DOMAIN       = localhost
HTTP_PORT        = 3000
ROOT_URL         =
DISABLE_SSH      = false
SSH_PORT         = 22
SSH_LISTEN_PORT  = 22
LFS_START_SERVER = false
LFS_CONTENT_PATH = /data/git/lfs
PROTOCOL         = https

And this is my server blocks (in http block) in /etc/nginx/nginx.conf:
        server {
            listen 80;
            listen [::]:80;
            server_name git.acaziasoft.com;

            location / {
                proxy_pass http://127.0.0.1:3000;
            }
        }
        server {
            listen 443 ssl;
            listen [::]:443 ssl;
            server_name git.acaziasoft.com;
            ssl on;
            ssl_certificate /etc/letsencrypt/live/git.acaziasoft.com/fullchain.pem;
            ssl_certificate_key /etc/letsencrypt/live/git.acaziasoft.com/privkey.pem;
            location / {
                proxy_pass http://unix:/var/run/gitea/gitea.sock;
            }
            access_log /var/log/nginx/gitea-proxy_access.log;
            error_log /var/log/nginx/gitea-proxy_error.log;
        }

In app.ini, if I change:
PROTOCOL         = https

to
PROTOCOL         = http

It works well and the site can be accessed (in http of course). But if I set it as PROTOCOL         = https then I always get 502 Bad Gateway error.
What could be wrong?

I believe if you configure HTTPS in app.ini you also have to configure the SSL certificates and the correct URI for Gitea.
I think SSL certificates inside a Docker container, unless it's a shared Docker hosting like AWS or a completely different host than the one that gets the DNS hostname, it's pretty useless...
Better thing to do IMO would be to host the Gitea container inside the same machine that hosts the proxy_pass webserver, and configure HTTPS only on Nginx.
Also, I see you do not redirect HTTP to HTTPS inside your Nginx configs; and also you configured the HTTP (port 80) server config to proxy the port 3000 on localhost, and the HTTPS block (port 443) to proxy for Gitea socket file (have you shared the socket file between the host and the container or what?).
I do not personally host Gitea inside a Docker container (as of now, planning to migrate), but I configured Gitea in plain HTTP on 127.0.0.1:8001 and SSL only on Nginx that redirects HTTP to HTTPS and HTTPS proxies to 127.0.0.1:8001.

Thank you @bryanpedini
It is now working as expected. I had to add extra port mapping to docker-compose.yml:
services:
  server:
    image: gitea/gitea:latest
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - DB_TYPE=postgres
      - DB_HOST=db:5432
      - DB_NAME=gitea
      - DB_USER=gitea
      - DB_PASSWD=gitea
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "22:22"
      - "5432:5432" # This one
    depends_on:
      - db

And the [server] block in app.ini. Since my Gitlab is hosted on Google Cloud, it has two IP: Internal and External.
[server]
APP_DATA_PATH    = /data/gitea
DOMAIN           = localhost
SSH_DOMAIN       = localhost
HTTP_PORT        = 3000
ROOT_URL         = http://<Internal_IP>:3000/ # This is the network's internal IP
DISABLE_SSH      = false
SSH_PORT         = 22
SSH_LISTEN_PORT  = 22
LFS_START_SERVER = false
LFS_CONTENT_PATH = /data/git/lfs
PROTOCOL         = http

And the two server blocks in nginx.conf:
        server {
            listen 80;
            listen [::]:80;
            server_name git.acaziasoft.com;

            location / {
                proxy_pass http://127.0.0.1:3000;
            }
        }
        server {
            listen 443 ssl;
            listen [::]:443 ssl;
            server_name git.acaziasoft.com;
            ssl on;
            ssl_certificate /etc/letsencrypt/live/git.acaziasoft.com/fullchain.pem;
            ssl_certificate_key /etc/letsencrypt/live/git.acaziasoft.com/privkey.pem;
            location / {
                proxy_pass http://127.0.0.1:3000; # This just simply points to localhost :D
            }
            access_log /var/log/nginx/gitea-proxy_access.log;
            error_log /var/log/nginx/gitea-proxy_error.log;
        }

With that, the site is up and running.

It is now working as expected. I had to add extra port mapping to docker-compose.yml:
    ports:
      - "3000:3000"
      - "22:22"
      - "5432:5432" # This one

Well, if you configured your DBMS (Postgres, in this case) on the host machine, yes, you have to forward the port (all tho I don't think that's the way to do it, since Docker probably throws an error for an already bound port on the host).
Why then having Gitea inside a Docker container then if you Docker-ize only Gitea and not Postgres too (I mean, there could be reasons, but I currently don't see 'em, okay it's 10am here in Italy and I'm still half asleep, but I still don't see 'em...)

And the [server] block in app.ini. Since my Gitlab is hosted on Google Cloud, it has two IP: Internal and External.

GitLab!?!?

And the two server blocks in nginx.conf:
        server {
            listen 80;
            listen [::]:80;
            server_name git.acaziasoft.com;

            location / {
                proxy_pass http://127.0.0.1:3000;
            }
        }
        server {
            listen 443 ssl;
            listen [::]:443 ssl;
            server_name git.acaziasoft.com;
            ssl on;
            ssl_certificate /etc/letsencrypt/live/git.acaziasoft.com/fullchain.pem;
            ssl_certificate_key /etc/letsencrypt/live/git.acaziasoft.com/privkey.pem;
            location / {
                proxy_pass http://127.0.0.1:3000; # This just simply points to localhost :D
            }
            access_log /var/log/nginx/gitea-proxy_access.log;
            error_log /var/log/nginx/gitea-proxy_error.log;
        }

Why didn't you redirected HTTP to HTTPS as I suggested? Is there a particular reason why you (seemingly intentionally) left HTTP as a reverse proxy to your Gitea too, instead of redirecting?
server {
    listen 80;
    server_name git.acaziasoft.com;
    return 301 https://$host$request_uri;
}

No... actually I dockerized db (Postgres too), the code above is just a part of it. The rest is:
  db:
    image: postgres:9.6
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=gitea
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - ./postgres:/var/lib/postgresql/data

This is a (mostly) copy-pasted from the Official Guide
Also, thank you for the snippet:
return 301 https://$host$request_uri;

The site now redirects to proper https link.

No... actually I dockerized db (Postgres too), the code above is just a part of it.

Then you don't need 5432:5432 in "ports" section, you need to have a "links" section, where you type in the name of the container you want to link to: see an example here

The site now redirects to proper https link. All these are new to me though.

Glad to have helped!

authors: Doko-Demo-Doa bryanpedini

repo: go-gitea/gitea


text:
Mastodon Oauth login is not functioning with pleroma/akkoma/newroma instances.

Description
The mastodon oauth login does not function with pleroma instances, you can enter the details and it will push the user to the oauth authorisation page but it will not allow the user to authorise the client, giving the error "incorrect username or password", it will not send the user back to gitea.
I have had this problem previously with a mediawiki mastodon integration and it was solved without modifications to pleroma, pronouns.page's mastodon integration also functions with pleroma, so this isn't a problem with my instance.
Gitea Version
1.17.3
Can you reproduce the bug on the Gitea demo site?
Cannot reproduce on demo instance as I would need the administration interface to add oauth.
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
Alpine Linux
How are you running Gitea?
Alpine linux package, nginx reverse proxy, mariadb database, authing with an akkoma instance that is proven to work with other oauth integrations.
Database
MySQL

It appears that the bug according to the logs is that gitea is expecting the site to provide an email for the registered user, but there is no apparent option to force gitea to use the activitypub username in place of the email.

I have just tested, you can link accounts to existing user accounts that already have emails attached, and successfully log in, but cannot create them due to the email requirement gitea has, I would say this is definitely a bug
I am including the error message:
OAuth2 Provider * returned empty or missing fields: [email] CreateUser: OAuth2 Provider * returned empty or missing fields: [email] router: completed GET /user/oauth2/*/callback?code=* for *:0, 500 Internal Server Error in 294.7ms @ auth/oauth.go:828(auth.SignInOAuthCallback)
@techknowlogick Are you able to take a look at this? Since there has been no activity in two weeks and it seems like a simple fix of just taking the mastodon username (@user@instance.tld) and applying that to the email field, in the same way pronouns.page does.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Zoom function for mermaid

Feature Description
Colleagues and me are a fan of the inclusion of mermaid and the ability to express entity relationship diagrams in plain English.
Github provides the ability zoom the resulting diagrams, whilst Gitea does not. Though you can use the browser native touch-zoom to view zoom the diagrams, on a classical PC without touchpad there is no way in Gitea to increase the size of the diagram, since it doesn't scale beyond the screen width when using standard page zoom. Rather frustrating when viewing bigger diagrams.
Zooming was supposed to be a feature to be included in mermaid itself, but it doesn't seem it will be included in mermaid-js itself, at least as far as I searched the issue tracker of mermaid-js. There are workarounds and CSS tweaks to allow zooming with standard page zoom or even proper zoom gizmo implementations: https://github.com/mermaid-js/mermaid/issues/1860
It would be excellent if there was any kind of way to realize this. Either through one of the workarounds suggested in the mermaid repo or in a more official capacity. Also I had to tweak the max chars allowed in the mermaid config, since our multi-language usage of it instantly blew past all defaults set by Gitea.
Here is a sample Diagram we use. Contents replaced with garbage from ChatGPT.
erDiagram
    "梅 | Plume" zero or many -- zero or one "苹果 | Apple" : "使用 | used"
    "梅 | Plume" one -- zero or many "香蕉 | Banana" : "使用 | used"

    "梅 | Plume" one -- zero or many "葡萄 | Grapes" : "使用 | used"
    "西瓜 | Watermelon" zero or many -- one "梅 | Plume" : "达成 | attains"
    "なんちゃらかんちゃら | OrangeAndLemon" one or many -- zero or many "梅 | Plume" : "使用 | used"
    "樱桃 | Cherry" zero or many -- one "梅 | Plume" : "达成 | attains"

    "梅 | Plume" one -- zero or many "菠萝 | Pineapple" : "执行 | performed"
    "梅 | Plume" one -- zero or many "猕猴桃 | Kiwi" : "执行 | performed"
    "梅 | Plume" one -- zero or many "草莓 | Strawberry" : "执行 | performed"

    "蓝莓 | Blueberry" one -- zero or many "木瓜 | Papaya" : "制造 | Extracts"
    "蓝莓 | Blueberry" one -- zero or many "橙子 | Orange" : "制造 | Extracts"

    "木瓜 | Papaya" one -- one or many "なんちゃらかんちゃら | OrangeAndLemon" : "选择 | chooses"
    "橙子 | Orange" one -- one or many "なんちゃらかんちゃら | OrangeAndLemon" : "选择 | chooses"

 "梅 | Plume" {
        time harvest_date "收获日期"
        text farmer_name "农民名, max_length=1000"
        int tree_serial_number FK "树编号, not blank"
        float ambient_temperature "环境温度, [℃], MinVal=-273.15, MaxVal=100"
        float ambient_humidity "环境湿度, [*100%], MinVal=0, MaxVal=1"
        float fruit_weight "水果重量, [g], MinVal=0, MaxVal=1000"
        text growth_location "生长地点, max_length=1000"
        text organization_name "组织名, max_length=1000"
        text farmer_name "农民名, not blank, max_length=1000"
        text inspector_name "检查员名, max_length=1000"
        text notes "备注, max_length=5000"
    }

    "苹果 | Apple" {
        char tree_serial_number PK "树编号, max_length=255"
        char tree_type "树类型, not blank, max_length=255"
    }

    "香蕉 | Banana" {
        char banana_variety "香蕉品种, not blank, max_length=255"
        float length "长度, [cm], MinVal=0, MaxVal=30"
    }

    "なんちゃらかんちゃら | OrangeAndLemon" {
        char batch_number "批次号, max_length=255"
    }

    "葡萄 | Grapes" {
        float sugar_content "糖分含量, [g/100g], MinVal=0, MaxVal=30"
        float bunch_weight "串重, [g], MinVal=0, MaxVal=1000"
        float vine_rotation_speed "葡萄藤旋转速度, [rpm], MinVal=0, MaxVal=10"
        float water_content "水分含量, [g/100g], MinVal=0, MaxVal=100"
        text growing_conditions_notes "生长条件备注, max_length=5000"
        float berry_diameter "葡萄粒直径, [mm], MinVal=0, MaxVal=30"
    }

    "西瓜 | Watermelon" {
        float weight "重量, [kg], MinVal=0, MaxVal=20"
        float sugar_content "糖分含量, [*100%], MinVal=0, MaxVal=1"
        float hardness "硬度, [Shore], MinVal=0, MaxVal=100"
        text eval_notes "评价备注, max_length=5000"
    }

    "樱桃 | Cherry" {
        bool ripe_status "成熟状态"
        text flavor_description "口感描述, max_length=1000"
        image cherry_image "樱桃图片"
        text eval_notes "评价备注, max_length=5000"
    }

    "菠萝 | Pineapple" {
        char ripening_method "成熟方法, max_length=255"
        float ripening_temperature "成熟温度, [℃], MinVal=-273.15, MaxVal=100"
        float pineapple_weight "菠萝重量, [kg], MinVal=0, MaxVal=5"
    }

    "猕猴桃 | Kiwi" {
        float resting_time_between_harvest "收获间隔时间, [d], MinVal=0, MaxVal=365"
        float resting_time_between_consume "消费间隔时间, [d], MinVal=0, MaxVal=365"
    }

    "草莓 | Strawberry" {
        char cooling_method "冷却方法, max_length=255"
        float pre_cooling_temperature "冷却前温度, [℃], MinVal=-273.15, MaxVal=100"
        float post_cooling_temperature "冷却后温度, [℃], MinVal=-273.15, MaxVal=100"
        float cooling_time "冷却时间, [h], MinVal=0, MaxVal=48"
    }
   "木瓜 | Papaya" {
          time ripeness_date "熟成年月日"
          text origin "産地, max_length=1000"
          int tree_age FK "木の年齢, not blank"
          float weight "重さ,[kg], MinVal=0, MaxVal=23"
          float sweetness "甘さ, [*100%], MinVal=0, MaxVal=1"
          float size "大きさ, [cm], MinVal=0, MaxVal=100"
          text color "色, max_length=1000"
          text flavor "風味, max_length=1000"
          text quality "品質, max_length=1000"
          text notes "メモ, max_length=5000"
    }

    "蓝莓 | Blueberry" {
        char id PK "ID, max_length=255"
        char variety "品種名, not blank, max_length=255"
    }

    "橙子 | Orange" {
        time ripeness_date "熟成年月日"
          text origin "産地, max_length=1000"
          int tree_age FK "木の年齢, not blank"
          float weight "重さ,[kg], MinVal=0, MaxVal=23"
          float sweetness "甘さ, [*100%], MinVal=0, MaxVal=1"
          float size "大きさ, [cm], MinVal=0, MaxVal=100"
          text color "色, max_length=1000"
          text flavor "風味, max_length=1000"
          text quality "品質, max_length=1000"
          text notes "メモ, max_length=5000"
    }

Screenshots
No response

Maybe have these buttons in a dialog view of the diagram. I find these overlay buttons too often hide vital content of a diagram with the way they are on GH.

Maybe have these buttons in a dialog view of the diagram. I find these overlay buttons too often hide vital content of a diagram with the way they are on GH.

I am open to any implementation. Right now, these diagrams are not usable on a PC without touchpad, since they can‘t be zoomed. Any and all solutions are fine by me.

We also have a huge class diagram which needs this feature. Will it be implemented later?

authors: FrostKiwi bioinformatist silverwind


text:
Wrong default branch while switching between branches via the web interface

Description
When switching between branches via the web interface, the default branch should remain unchanged.

e.g. The default branch should remain main
Gitea Version
latest codebase
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
building Gitea from source code
Database
None

@yp05327

caused by pr #26697

$defaultBranch is not the repo's default branch, the existing code is confusing.


text:
Open PR failed

Description
The open PR request is 500. It is possible that this PR is relatively large, it's timeout.
15752 changed files with 216833 additions and 95254 deletions
2024/03/25 12:02:47 ...eb/routing/logger.go:68:func1() [W] router: slow      GET /xxx/test/compare/tmaster...unify_new for xxx:0, elapsed 3894.4ms @ repo/compare.go:714(repo.CompareDiff)
2024/03/25 12:03:13 ...eb/routing/logger.go:68:func1() [W] router: slow      POST /xxx/test/compare/tmaster...unify_new for xxx:0, elapsed 3387.6ms @ repo/pull.go:1375(repo.CompareAndPullRequestPost)
2024/03/25 12:09:22 ...ll/patch_unmerged.go:164:unmergedFiles() [E] Unable to run ls-files -u -z! Error: git ls-files -u -z: context deadline exceeded
2024/03/25 12:09:22 ...ers/web/repo/pull.go:1475:CompareAndPullRequestPost() [E] NewPullRequest: unable to run ls-files -u -z! Error: git ls-files -u -z: context deadline exceeded

Gitea Version
1.21.8
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
1.21.8

try.gitea.io

Git Version
2.40.1
Operating System
docker
How are you running Gitea?
docker gitea/gitea:1.21.8-rootless
Database
PostgreSQL

Maybe this can help you:
https://github.com/go-gitea/gitea/issues/27967#issuecomment-1802737143

We close issues that need feedback from the author if there were no new comments for a month. :tea:

authors: GiteaBot PittyXu yp05327


text:
gitgraph

feature request/discussion:
I know there have been some feature requests for something that visually shows the branches in a repository.
for instance gogits/gogs#1339
I have played a bit with https://github.com/bluef/gitgraph.js - see screnshot: http://imgur.com/aPlsCtY
I know this feature is not scheduled for next release, but what is your thoughts on this apporach? I could create a pull-request of this approach would be considered.

I like that and we are open for pull requests. But I think this can be merged after 1.0 branch.

resolved by #428

authors: kjellkvinge lunny tboerger


text:
Fix creating OAuth2 auth source from CLI

This MR fixing creation OAuth2 auth source from CLI.
Problem is described here: https://github.com/go-gitea/gitea/issues/8356

Codecov Report

Merging #14116 (0497101) into master (4d22e24) will increase coverage by 0.00%.
The diff coverage is 18.75%.

@@           Coverage Diff           @@
##           master   #14116   +/-   ##
=======================================
  Coverage   42.34%   42.34%
=======================================
  Files         726      726
  Lines       77839    77852   +13
=======================================
+ Hits        32960    32967    +7
- Misses      39462    39469    +7
+ Partials     5417     5416    -1

Impacted Files
Coverage Δ

modules/auth/oauth2/oauth2.go
27.27% <0.00%> (-0.36%)
:arrow_down:

routers/user/auth.go
11.97% <0.00%> (-0.08%)
:arrow_down:

models/oauth2.go
34.14% <50.00%> (+0.81%)
:arrow_up:

modules/git/tree_entry_nogogit.go
87.50% <0.00%> (-6.25%)
:arrow_down:

modules/process/manager.go
72.50% <0.00%> (-2.50%)
:arrow_down:

models/error.go
38.98% <0.00%> (+0.48%)
:arrow_up:

services/pull/pull.go
42.85% <0.00%> (+0.50%)
:arrow_up:

modules/indexer/stats/db.go
48.00% <0.00%> (+8.00%)
:arrow_up:

modules/indexer/stats/queue.go
76.47% <0.00%> (+11.76%)
:arrow_up:

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 30edcd5...0497101. Read the comment docs.

make lg-tm work

source: gharchive/pull-request

authors: codecov-io daniil-pankratov zeripath


text:
Performance improvement for last commit cache and show-ref

Continuing on from #15447
This PR is an attempt to reduce the performance issues noted in #15413 and #15401

Codecov Report

Merging #15455 (de49ada) into master (fda2e45) will decrease coverage by 0.00%.
The diff coverage is 86.66%.

@@            Coverage Diff             @@
##           master   #15455      +/-   ##
==========================================
- Coverage   43.91%   43.90%   -0.01%
==========================================
  Files         678      678
  Lines       81827    81838      +11
==========================================
+ Hits        35932    35933       +1
- Misses      40051    40055       +4
- Partials     5844     5850       +6

Impacted Files
Coverage Δ

modules/git/last_commit_cache_nogogit.go
35.18% <50.00%> (-1.36%)
:arrow_down:

modules/git/commit_info_nogogit.go
70.09% <100.00%> (+0.29%)
:arrow_up:

modules/git/repo_commit_nogogit.go
66.19% <100.00%> (+5.25%)
:arrow_up:

modules/indexer/stats/db.go
50.00% <0.00%> (-10.72%)
:arrow_down:

modules/git/tree_nogogit.go
60.86% <0.00%> (-8.70%)
:arrow_down:

modules/process/manager.go
72.83% <0.00%> (-2.47%)
:arrow_down:

modules/git/repo_language_stats_nogogit.go
44.57% <0.00%> (-2.41%)
:arrow_down:

modules/queue/workerpool.go
58.77% <0.00%> (-1.23%)
:arrow_down:

models/repo_list.go
77.04% <0.00%> (-0.78%)
:arrow_down:

routers/repo/view.go
41.24% <0.00%> (+0.58%)
:arrow_up:

... and 1 more

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 fda2e45...de49ada. Read the comment docs.

authors: codecov-commenter zeripath


text:
Use full output of git show-ref --tags to get tags for PushUpdateAddTag

Strangely #19038 appears to relate to an issue whereby a tag appears to
be listed in git show-ref --tags but then does not appear when git show-ref --tags -- short_name is called.
As a solution though I propose to stop the second call as it is
unnecessary and only likely to cause problems.
I've also noticed that the tags calls are wildly inefficient and aren't using the common cat-files - so these have been added.
I've also noticed that the git commit-graph is not being written on mirroring - so I've also added writing this to the migration which should improve mirror rendering somewhat.
Fix #19038
Signed-off-by: Andrew Thornton art27@cantab.net

wake up :robot:


text:
Branches management UI

As title. This should be the first step to move commits, branches, tags as a submenu of Code.

@ethantkoenig all done.

Would be nice to provide screenshots, otherwise LGTM

I am for adding some example screenshots too.

Just found a bug

seems this is duplicated with #2108

Yes these PR need to be merged in one :)

#2108 will replace this one, so I close here.

authors: Morlinest ethantkoenig lafriks lunny


text:
fix: Add feed for organization

fixed #3593
screenshot:

Codecov Report

Merging #3594 into master will decrease coverage by <.01%.
The diff coverage is 18.18%.

@@            Coverage Diff             @@
##           master    #3594      +/-   ##
==========================================
- Coverage   36.16%   36.15%   -0.01%
==========================================
  Files         285      285
  Lines       40905    40916      +11
==========================================
+ Hits        14792    14794       +2
- Misses      23941    23949       +8
- Partials     2172     2173       +1

Impacted Files
Coverage Δ

models/repo_watch.go
67.56% <18.18%> (-8.63%)
:arrow_down:

models/repo_indexer.go
48.3% <0%> (ø)
:arrow_up:

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 2cd3622...1e47d47. Read the comment docs.

@thehowl Thanks for your review. I don't know why it can't work for the current version. It is working before v1.3 version reported from someone in #chinese channel of discord.

LGTM

authors: appleboy codecov-io lunny


text:
Update mssql driver

The mssql driver was blocked to an old version of 2016 because of a replace rule.
Changelog: https://github.com/denisenkom/go-mssqldb/compare/e32ca5036449...master

Migrations does not seem to work anymore

Looking at some of the logs it seems that during migration tests an earlier migration didn’t empty as there are errors about duplicate table:
Error: mssql: There is already an object named 'access_token' in the database.

Looks like dropping the database between the migration tests didn't work

They should be being dropped by:
https://github.com/go-gitea/gitea/blob/7dd983797c218d7ae45e67d79517e95ad3dd24b8/integrations/migration-test/migration_test.go#L199
But this doesn't seem to be happening and it doesn't seem to be complaining about it

Has some auto transaction support been added? It might be that it's expecting us to commit before it moving on?

I forget that I have done this PR before :man_facepalming:.
This is now superseded by #7306 and futur work in #7294 to completely remove the replace in go.mod.

authors: lafriks sapk techknowlogick zeripath


text:
Issue with Migration rule v111

I was facing some issues with migration rule v111
Please check the following:

Make sure you are targeting the master branch, pull requests on release branches are only allowed for bug fixes.
Read contributing guidelines: https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md
Describe what your pull request does and which issue you're targeting (if any)

You MUST delete the content above including this line before posting, otherwise your pull request will be invalid.

Codecov Report

Merging #9449 into master will increase coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #9449      +/-   ##
==========================================
+ Coverage   41.51%   41.51%   +<.01%
==========================================
  Files         570      570
  Lines       74639    74642       +3
==========================================
+ Hits        30983    30988       +5
+ Misses      39818    39813       -5
- Partials     3838     3841       +3

Impacted Files
Coverage Δ

models/migrations/v111.go
0% <0%> (ø)
:arrow_up:

services/pull/temp_repo.go
31.62% <0%> (-2.57%)
:arrow_down:

models/repo_list.go
74.07% <0%> (+0.92%)
:arrow_up:

models/unit.go
67.56% <0%> (+5.4%)
:arrow_up:

modules/indexer/code/indexer.go
55.26% <0%> (+10.52%)
:arrow_up:

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 f8a6eb8...8499956. Read the comment docs.

authors: MarcelHillmann codecov-io


text:
WIP Global issue search

Added search box on dashboard issues page; searches across user's repositories as appropriate.
Ref issue: #2434

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@9176642). Click here to learn what that means.
The diff coverage is 44.48%.

@@            Coverage Diff            @@
##             master    #9758   +/-   ##
=========================================
  Coverage          ?   42.32%
=========================================
  Files             ?      599
  Lines             ?    78386
  Branches          ?        0
=========================================
  Hits              ?    33175
  Misses            ?    41153
  Partials          ?     4058

Impacted Files
Coverage Δ

models/repo_branch.go
100% <ø> (ø)

modules/auth/admin.go
0% <ø> (ø)

modules/setting/git.go
65.38% <ø> (ø)

models/migrations/migrations.go
1.3% <ø> (ø)

services/pull/patch.go
62.65% <0%> (ø)

modules/repository/repo.go
26.28% <0%> (ø)

models/lfs.go
17.27% <0%> (ø)

modules/migrations/gitea.go
7.96% <0%> (ø)

routers/admin/repos.go
0% <0%> (ø)

routers/admin/orgs.go
0% <0%> (ø)

... and 49 more

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 9176642...1491e24. Read the comment docs.

I think this should be issue search on my related repositories but not a generic global issue search on all the public repositories.

authors: bhalbright codecov-io lunny


text:
many to many joinForeignKey auto formated

Your Question

Is there a way to limit foreignKey , joinForeignKey to auto camelcase?
The document you expected this should be explained
I want to use associations many to many, I declare joinForeignKey:xxxYYY to overwrite key, it auto converted to xxx_yyy.
Due to historical reasons, there are different field formats in the database, egxxxYYY, xxx_yyy, xxxyyy

Expected answer

A way to let  joinForeignKey:xxxYYY keeps the statement as it is

https://gorm.io/docs/gorm_config.html#NamingStrategy

repo: go-gorm/gorm


text:
Introduce go modules

go test fails because we do not have dependency management systems introduced.
I added go modules (go.mod, go.sum) in order to introduce it and pass tests.

Go modules are supported in version branches, not in master.  If you would like to discuss why this is, I am happy to chat in gitter or even have a video call - but master must be kept modules-free.

authors: nelsam rinchsan

repo: go-gorp/gorp

license: mit

license_source: bigquery


text:
detect missing in/out ports

fwk should bail out (with a helpful message) when there is an inconsistent graph of input/output nodes, in the dataflow.

This issue was moved to go-hep/sw#3

repo: go-hep/fwk


text:
feat: add nacos discovery

feat: add nacos discovery

feat: add nacos discovery

test

添加nacos发现服务

添加rewrite中间件rewritepathto, 替换path里面rewritepath变成rewritepathto

repo: go-kratos/gateway


text:
Support go modules

Support go module versioning conventions and when used don't redirect to gopkg.in/mail.v2
https://github.com/golang/go/wiki/Modules#semantic-import-versioning

@Scapal I just tagged v2.3.0 with support for Go modules. Let me know if this fixes your issue.

This has broken both modules and go get. :(
According to the go.mod if using modules you must import with github.com/go-mail/mail/v2 however, if you doing that it breaks go get as there is no path on GitHub to match that.
It's important that the module name also match the import path for those not currently using modules, which is a lot of people.
The suggested route to solve this problem is to create a /v2 folder in the repo, that contains the v2 module and code. This allows for people to migrate to /v2 at their leisure, while not breaking those trying to support both go modules and go get.
Please consider either rolling back this change or making the suggested corrections. Thanks.
This release has broken https://gobuffalo/buffalo.

@markbates Apologies for the trouble. What does your go version report? From what I read, specifying /v2 should work for branches too:

Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above).

Also, from looking at your commit in gobuffalo/buffalo@95c2e1a687eebb1eb03d940a96435bb8f2109f56, I notice you were using @alexcesaro's (upstream) import path, gopkg.in/gomail.v2, and not gopkg.in/mail.v2. Was that intentional?
To use this fork, you'll want to import either:

github.com/go-mail/mail - This should be the latest HEAD of the v2 branch.
github.com/go-mail/mail/v2 - If using Go modules, this should be the latest v2.*.* tag.
gopkg.in/mail.v2 - This should be the latest HEAD of the v2 branch.

I'll double check to be sure I'm not making an obvious mistake here. If anyone else can confirm this breakage, we can roll this back. 😅

Also, the branch “solution” means no one using non-modules can get it with go get.
It’s your repo and you can’t obviously, support modules the way you want, but it would be nice if you can make it work for everyone.
Thanks.
On Nov 12, 2018, 12:57 PM -0500, Ivy Evans notifications@github.com, wrote:

@markbates Apologies for the trouble. What does your go version report? From what I read, specifying /v2 should work for branches too:

Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above).
Also, from looking at your commit in gobuffalo/buffalo@95c2e1a, I notice you were using @alexcesaro's (upstream) import path, gopkg.in/gomail.v2, and not gopkg.in/mail.v2. Was that intentional?
To use this fork, you'll want to import either:

• github.com/go-mail/mail - This should be the latest HEAD of the v2 branch.
• github.com/go-mail/mail/v2 - If using Go modules, this should be the latest v2.. tag.
• gopkg.in/mail.v2 - This should be the latest HEAD of the v2 branch.
I'll double check to be sure I'm not making an obvious mistake here. If anyone else can confirm this breakage, we can roll this back. 😅
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

We tried using http://gopkg.in/mail.v2 too, but again, modules and import paths don’t match.
The problem here is there needs to be a single import path that works for non-modules and modules alike. Currently it’s not possible to import this package and have it resolve in both.
They have to match for Go to work. We ended up having to internalize the package as it’s broken.
On Nov 12, 2018, 12:57 PM -0500, Ivy Evans notifications@github.com, wrote:

@markbates Apologies for the trouble. What does your go version report? From what I read, specifying /v2 should work for branches too:

Go versions 1.9.7+, 1.10.3+, and 1.11 are able to properly consume and build a v2+ module created using this approach without requiring updates to consumer code that has not yet opted in to modules (as described in the the "Semantic Import Versioning" section above).
Also, from looking at your commit in gobuffalo/buffalo@95c2e1a, I notice you were using @alexcesaro's (upstream) import path, gopkg.in/gomail.v2, and not gopkg.in/mail.v2. Was that intentional?
To use this fork, you'll want to import either:

• github.com/go-mail/mail - This should be the latest HEAD of the v2 branch.
• github.com/go-mail/mail/v2 - If using Go modules, this should be the latest v2.. tag.
• gopkg.in/mail.v2 - This should be the latest HEAD of the v2 branch.
I'll double check to be sure I'm not making an obvious mistake here. If anyone else can confirm this breakage, we can roll this back. 😅
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@markbates I understand your frustration and I want to help. A number of users have expressed interest in utilizing Go modules and I'm only supporting it under the condition that it works for everyone. I want to find a solution that works for us all and in order to do that, I need a bit more detail…

What go version are you using?
What exact error messages are you getting?

I just tried importing go-mail with a pristine GOPATH without any trouble. One hiccup I noticed, however was that I needed my project to reside within GOPATH, otherwise I get:
main.go:7:2: cannot find package "gopkg.in/mail.v2" in any of:
	/usr/local/Cellar/go/1.11.2/libexec/src/gopkg.in/mail.v2 (from $GOROOT)
	/Users/ivy/test/go/src/gopkg.in/mail.v2 (from $GOPATH)

After making sure my project was moved/symlinked into GOPATH, I had no trouble outside of a small warning:
go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src;
	ignoring ../../../go.mod;
	see 'go help modules'
Fetching https://gopkg.in/mail.v2?go-get=1
Parsing meta tags from https://gopkg.in/mail.v2?go-get=1 (status code 200)
get "gopkg.in/mail.v2": found meta tag get.metaImport{Prefix:"gopkg.in/mail.v2", VCS:"git", RepoRoot:"https://gopkg.in/mail.v2"} at https://gopkg.in/mail.v2?go-get=1
gopkg.in/mail.v2 (download)
gopkg.in/mail.v2
test

Is this the same case for you too?

With mods on (off works fine):
go get gopkg.in/mail.v2

go: gopkg.in/mail.v2@v2.3.0: go.mod has non-....v2 module path "github.com/go-mail/mail/v2" at revision v2.3.0
go: error loading module requirements

With mods off (mods are fine):
go get github.com/go-mail/mail/v2

package github.com/go-mail/mail/v2: cannot find package "github.com/go-mail/mail/v2" in any of:
	/usr/local/go/src/github.com/go-mail/mail/v2 (from $GOROOT)
	/Users/markbates/Dropbox/go/src/github.com/go-mail/mail/v2 (from $GOPATH)

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/markbates/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/markbates/Dropbox/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/markbates/Dropbox/go/src/github.com/gobuffalo/buffalo/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2 -w"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zj/ktv0trrj4l79dfq0dkm1b6d40000gn/T/go-build141527679=/tmp/go-build -gno-record-gcc-switches -fno-common"

It's easy to reproduce. You just need to pick an import path, and support that one.

I’m also in my GOPATH as I work exclusively there. This was also reported by other members of the team, the community, Travis, etc...
Trust me when I say this broke stuff for people. This got released and all of a sudden everything came to grinding halt.
You also can’t rever the change now either as go modules will pick up the last release with a go.mod file; so you can’t revert and need to fix the problem head on.
On Nov 12, 2018, 1:20 PM -0500, Ivy Evans notifications@github.com, wrote:

@markbates I understand your frustration and I want to help. A number of users have expressed interest in utilizing Go modules and I'm only supporting it under the condition that it works for everyone. I want to find a solution that works for us all and in order to do that, I need a bit more detail…
• What go version are you using?
• What exact error messages are you getting?
I just tried importing go-mail with a pristine GOPATH without any trouble. One hiccup I noticed, however was that I needed my project to reside within GOPATH, otherwise I get:
main.go:7:2: cannot find package "gopkg.in/mail.v2" in any of:
/usr/local/Cellar/go/1.11.2/libexec/src/gopkg.in/mail.v2 (from $GOROOT)
/Users/ivy/test/go/src/gopkg.in/mail.v2 (from $GOPATH)
After making sure my project was moved/symlinked into GOPATH, I had no trouble outside of a small warning:
go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src;
ignoring ../../../go.mod;
see 'go help modules'
Fetching https://gopkg.in/mail.v2?go-get=1
Parsing meta tags from https://gopkg.in/mail.v2?go-get=1 (status code 200)
get "gopkg.in/mail.v2": found meta tag get.metaImport{Prefix:"gopkg.in/mail.v2", VCS:"git", RepoRoot:"https://gopkg.in/mail.v2"} at https://gopkg.in/mail.v2?go-get=1
gopkg.in/mail.v2 (download)
gopkg.in/mail.v2
test
Is this the same case for you too?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I’ve been working closely with members of the Go team on improving modules support, and I’ve brought this ticket to their attention as an experience report. Hopefully it’ll help them with docs and improvement s

FYI, for a package maintainer, opting into modules for a non-v1 package is a breaking change.
e.g. the version of Go the downstream package(s) uses needs to support modules and import paths need to be updated since it's a non-v1 package.

You also can’t rever the change now either as go modules will pick up the last release with a go.mod file; so you can’t revert and need to fix the problem head on.

You actually can revert the change in v2 and support modules in v3. go get and any module aware dependency manager will do the right thing. The problem is that not all dependency managers are module aware. For golang-migrate, I had to back-out module support in v3 and support modules in v4.
@markbates I believe you need to use github.com/go-mail/mail/v2 imports with modules enabled. You can also look into using the replace directive as a big hammer, but that probably won't help with gobuffalo since it only works for the top-level package. e.g. consumers of gobuffalo would also need to use replace.

Using go modules, outside GOPATH, it works as expected.
imported as "github.com/go-mail/mail/v2"
It creates the following entry in my go.mod:
github.com/go-mail/mail/v2 v2.3.0

No error nor warning during testing or compilation.

again, this is broken if you want to use the same import path for both mods or non-mods.
We’ve internalized the package because this is broken. It’s easy to reproduce in the GOPATH.
Pick an import path and support just the one. It’s that simple.
I get the impression, from this ticket, that there is no interest in changing that. Again, not my project, so I can’t dictate.
I’m moving on from this issue; since we’ve fixed it by censoring for now.
If this gets fixed, we’ll remove the vendor.
Please consider fixing

I can confirm what @markbates said: we need to support both users using go modules and those who don't, that's why the current solution can't work.

We are affected by this problem. Please consider to fix it.

Okay, the fix I'm considering is:

I can remove the go.mod file and tag a new v2.3.1 release. This should fix the issue for almost everyone, correct?

I can also delete the v2.3.0 tag. At least, that seems like the solution to @markbates's earlier response:

You also can’t rever the change now either as go modules will pick up the last release with a go.mod file; so you can’t revert and need to fix the problem head on.

Can anyone sanity check this solution to be sure I don't inadvertantly make things worse?

v2.3.1 is tagged and removes the go.mod manifest. I'm going to hold off on deleting the v2.3.0 tag until someone more knowledgable can chime in (I imagine a go mod cache purge will be needed). Sorry for the inconvenience!

Snag is @ivy

That i lost trust with gopkg.in
then embraced this fork in same manner..
But its stunk me a few times (other project also) so i lost trust in  gopkg.in for that reason

The new go.mod solves the problem...

I'm going to assume by the silence that there's no need to yank the previous tag.

@pedromorgan Agreed 100%, Gopkg.in is no longer necessary. It's really only around for the small minority of developers who might still rely on v1 or an older Go. I'm open to deprecating it.
Unfortunately, the go.mod addition created more problems than it solved…

I believe @dhui is right, it's safe to keep v2 as it is and switch to go modules in v3 that you could start as soon as you can, (even if it's just for that ?).
Go modules is more and more in use even buffallo use it and need Go 1.9.7+ , it will be a shame to don't jump in the wagon.

It's been a while; let's revisit this.
The Go wiki has some guidelines on how to migrate a package to modules that is already on a version >= 2.0: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher. The general advice they give is to bump up to a new major version (so dep, etc. can stick with their current version), and to either put the new major version on a separate branch or in a subdirectory. Given the stability of this library, I think the major branch approach would be fine, although it would probably prevent dep from importing v3 until https://github.com/golang/dep/issues/1962 is fixed.
I can submit a quick PR that adds modules at v3, but the important parts of the process will be outside the scope of the PR:

(Optional) Create a v3 branch and make it the repo default. There are a couple reasons to do this. First, the dep issue I previously mentioned will prevent dep from importing v3, so creating a separate branch would allow important future updates to be easily backported to v2 for dep users. Second, this would be friendlier to legacy go get users who are just grabbing master.
Tag the new commit at v3.0.0.

If you want more info about this process, the wiki link above has links to more resources.

authors: Scapal bvisness dhui dreampuf flibustenet ivy markbates pedromorgan stanislas-m

repo: go-mail/mail


text:
Improve error types to allow wrapping

I got stymied not having an idiomatic way of seeing whether a smartcard object was not found or not, and I saw the TODO in the code to list error cases, so I thought I'd offer this improvement for comment.

Promotes apduError to a public ApduError type
Adds error messages from the latest PIV spec
Uses error Unwrap() to return a few more accessible/idiomatic Go errors to enable some errors.Is and errors.As uses, such as ErrNotFound, ErrBlocked
Promotes errWrongPin to VerifyErr type
Changes all %v verbs to %w when wrapping errors (new in 1.13, which is what go.mod says we are)
The above changes made ykTransmit unnecessary, so removed

I can now do things like:
// Don't overwrite a slot
_, err = yk.Certificate(slot)
if err == nil {
  return errSlotOccupied
} else if !errors.Is(err, piv.ErrNotFound) {
  return err
}

Fixes #13

I'm fine with ErrNotFound and improving the error message. Please add a test for that one :)
Less convinced that we need to expose so much API surface to deal with errors. Maybe ErrWrongPIN is worth exposing, but what practical program is going to do anything except return that error to the user? Definitely think that we shouldn't expose apduError. It way too low level, and I'd rather add specific error conditions to the API, like an object not being found.

OK, that makes sense.  I'll pull this back to expose less, which means the %w changes add less value so I'll drop those as well.
The ykTransmit drop was intentional, though, as this function was essentially a no-op after the error handling got moved out of it.  This will be clearer with the reversions suggested.

OK I believe I've made all of the changes you suggested and added tests.  PTAL.

Changes made and squashed.
I also made one additional small change to the error message text returned by apduErr.Error() for the 'blocked' case, to allow someone to distinguish between "verification failed" and "method blocked" there since AuthErr has the same value for each.  And added a test for that.

Thanks for the couple iterations :) If you hit any other use cases where it'd be good to expose another error type, please let me know. Will tag a release later this evening

authors: dnesting ericchiang

repo: go-piv/piv-go


text:
Not work go get

go get gopkg.in/bluesuncorp/validator.v5
not work on centos, but yes on mac and ubuntu. With -v i see lock on download

What version(s) of Go are on each machine? Validator needs at least v1.3, just a guess. Could you also output the-v output?

Is there anything special about the centos box vs Mac or Ubuntu ones? I.e. same location, behind firewall's...
It does not seem to be an issue with validator, github or gopkg.in.

I got same problem. It is ok under my macbook. But it got hanged under CentOS 6.7. My macbook and the server were under the same network.
My go version is 1.5.1. My console output is below.
[work@spider0 xmspider]$ go get -v github.com/gin-gonic/gin
Fetching https://gopkg.in/bluesuncorp/validator.v5?go-get=1
Parsing meta tags from https://gopkg.in/bluesuncorp/validator.v5?go-get=1 (status code 200)
get "gopkg.in/bluesuncorp/validator.v5": found meta tag main.metaImport{Prefix:"gopkg.in/bluesuncorp/validator.v5", VCS:"git", RepoRoot:"https://gopkg.in/bluesuncorp/validator.v5"} at https://gopkg.in/bluesuncorp/validator.v5?go-get=1
gopkg.in/bluesuncorp/validator.v5 (download)
^C[work@spider0 xmspider]$ go version
go version go1.5.1 linux/amd64

@odinliu could I get a few more details, I believe it is an issue with centos itself, but I'm sure I can help in narrowing it down.

How was go installed? Compiled, rpm....
Can you go get any other packages?
3a. Can you go get validator directly with Go get gopkg.in/bluesuncorp/validator.v5 ? maybe a problem with gin and the godep programming that is being used
3b. Does go get gopkg.in/go-playground/validator.v5 work? Maybe a GitHub redirecting issue from old bluesuncorp to go-playgroind.
What kernel version is in use, and how was that installed ?I.e. standard kernel or compiled custom.
What version of git is installed?

I still have a hard time believing it is the package itself as go get is essentially just a git clone, but I'm sure we can figure something out

@joeybloggs thx a lot

I install go with the linux binary release. (https://storage.googleapis.com/golang/go1.5.2.linux-amd64.tar.gz)

I can download other packages, except from golang.org. because it can not visit directly in China.

I can't. Secondly I tried, it has been hanged.

[odin@namenode0 ~]$ go get -u -v gopkg.in/bluesuncorp/validator.v5
Fetching https://gopkg.in/bluesuncorp/validator.v5?go-get=1
https fetch failed.
import "gopkg.in/bluesuncorp/validator.v5": https fetch: Get https://gopkg.in/bluesuncorp/validator.v5?go-get=1: net/http: TLS handshake timeout
package gopkg.in/bluesuncorp/validator.v5: unrecognized import path "gopkg.in/bluesuncorp/validator.v5"
[odin@namenode0 ~]$ curl -v 'https://gopkg.in/bluesuncorp/validator.v5?go-get=1'
* About to connect() to gopkg.in port 443 (#0)
*   Trying 107.178.216.236... connected
* Connected to gopkg.in (107.178.216.236) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* 	subject: E=gustavo@niemeyer.net,CN=www.gopkg.in,C=BR
* 	start date: Mar 03 20:36:52 2015 GMT
* 	expire date: Mar 03 07:12:49 2016 GMT
* 	common name: www.gopkg.in
* 	issuer: CN=StartCom Class 1 Primary Intermediate Server CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
> GET /bluesuncorp/validator.v5?go-get=1 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: gopkg.in
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html
< Date: Wed, 16 Dec 2015 16:08:44 GMT
< Content-Length: 402
<

<html>
<head>
<meta name="go-import" content="gopkg.in/bluesuncorp/validator.v5 git https://gopkg.in/bluesuncorp/validator.v5">
<meta name="go-source" content="gopkg.in/bluesuncorp/validator.v5 _ https://github.com/bluesuncorp/validator/tree/v5.12{/dir} https://github.com/bluesuncorp/validator/blob/v5.12{/dir}/{file}#L{line}">
</head>
<body>
go get gopkg.in/bluesuncorp/validator.v5
</body>
</html>
* Connection #0 to host gopkg.in left intact
* Closing connection #0
[odin@namenode0 ~]$ go get -u -v gopkg.in/bluesuncorp/validator.v5
Fetching https://gopkg.in/bluesuncorp/validator.v5?go-get=1
Parsing meta tags from https://gopkg.in/bluesuncorp/validator.v5?go-get=1 (status code 200)
get "gopkg.in/bluesuncorp/validator.v5": found meta tag main.metaImport{Prefix:"gopkg.in/bluesuncorp/validator.v5", VCS:"git", RepoRoot:"https://gopkg.in/bluesuncorp/validator.v5"} at https://gopkg.in/bluesuncorp/validator.v5?go-get=1
gopkg.in/bluesuncorp/validator.v5 (download)

Just got hanged too.

[odin@namenode0 ~]$ go get -u -v gopkg.in/go-playground/validator.v5
Fetching https://gopkg.in/go-playground/validator.v5?go-get=1
Parsing meta tags from https://gopkg.in/go-playground/validator.v5?go-get=1 (status code 200)
get "gopkg.in/go-playground/validator.v5": found meta tag main.metaImport{Prefix:"gopkg.in/go-playground/validator.v5", VCS:"git", RepoRoot:"https://gopkg.in/go-playground/validator.v5"} at https://gopkg.in/go-playground/validator.v5?go-get=1
gopkg.in/go-playground/validator.v5 (download)

A standard kernel with CentOS 6.7

[odin@namenode0 ~]$ cat /etc/centos-release
CentOS release 6.7 (Final)
[odin@namenode0 ~]$ uname -a
Linux namenode0 2.6.32-573.8.1.el6.x86_64 #1 SMP Tue Nov 10 18:01:38 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

some versions

[odin@namenode0 ~]$ go version
go version go1.5.2 linux/amd64
[odin@namenode0 ~]$ git --version
git version 1.7.1

I can get validator under my windows, either. And if I copy $GOPATH/src/gopkg.in/bluesuncorp/validator.v5 directly from my mac/win to centos, I can run go get then.

[odin@namenode0 ~]$ go get -u -v gopkg.in/bluesuncorp/validator.v5
Fetching https://gopkg.in/bluesuncorp/validator.v5?go-get=1
Parsing meta tags from https://gopkg.in/bluesuncorp/validator.v5?go-get=1 (status code 200)
get "gopkg.in/bluesuncorp/validator.v5": found meta tag main.metaImport{Prefix:"gopkg.in/bluesuncorp/validator.v5", VCS:"git", RepoRoot:"https://gopkg.in/bluesuncorp/validator.v5"} at https://gopkg.in/bluesuncorp/validator.v5?go-get=1
gopkg.in/bluesuncorp/validator.v5 (download)
gopkg.in/bluesuncorp/validator.v5
[odin@namenode0 ~]$

@odinliu I think I may have discovered the problem, I think it may be the git version 1.7.1
I read a bunch of articles like this one https://github.com/spf13/hugo/issues/297 where they were having the same sort of issue.
because I'm using gopkg.in for my versioning it does a redirect to the real git branch to get the code and go get just proxies git and git 1.7.1 is not handling to redirects properly.
Is it possible to upgrade your version of git and try again?

@joeybloggs thanks! It works! I updated my git from 1.7.1 to 2.6.4, and it just works.
CentOS 6 is really out of fashion, with gcc-4.4.7, kernel-2.6.x and so on.

Great! @odinliu glad in the end it's a simple fix.
I agree with centos being behind, it has it's purpose being stable and all but IMHO in todays rapidly shifting, changing and advancing software and technology that sort of mentality can get you left behind.
I'll leave this up for a bit so others with the same problem can check for the solution.
Thanks for all your help in narrowing the problem down :thumbsup:

In my case, it doesn't work though I have upgraded git (2.10.0) and go(1.7.1).
OS is CentOS 6.3
It is still hanged like below.
Fetching https://gopkg.in/go-playground/validator.v8?go-get=1
Parsing meta tags from https://gopkg.in/go-playground/validator.v8?go-get=1 (status code 200)
get "gopkg.in/go-playground/validator.v8": found meta tag main.metaImport{Prefix:"gopkg.in/go-playground/validator.v8", VCS:"git", RepoRoot:"https://gopkg.in/go-playground/validator.v8"} at https://gopkg.in/go-playground/validator.v8?go-get=1
gopkg.in/go-playground/validator.v8 (download)

Hello @laeshiny
I'm definitely willing to help, this must be an external issue though.

Can you confirm that the git version in your current terminal session is using git 2.10.0 using git --version maybe it's using another found earlier within the $PATH

Confirm go version using command go version

If both 1 and 2 are ok can you do a regular git clone of the repo?

Other thoughts are github.com or gopkg.in could be experiencing issues; it's rare but it happens.

Are you able to try with any other is besides CentOS? Issues like these seem to always happen with it.

Perhaps try running command as root, I think that go get suppresses some of the git clone errors, but unlikely.

Let me know and I'll post of I can think of any more.

Answer is like below

Can you confirm that the git version in your current terminal session is using git 2.10.0 using git --version maybe it's using another found earlier within the $PATH

Confirm go version using command go version
$ go version
go version go1.7.1 linux/amd64
$ git version
git version 2.10.0

If both 1 and 2 are ok can you do a regular git clone of the repo?
$ git clone https://github.com/go-playground/validator
Cloning into 'validator'...
remote: Counting objects: 1752, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 1752 (delta 7), reused 0 (delta 0), pack-reused 1733
Receiving objects: 100% (1752/1752), 756.42 KiB | 262.00 KiB/s, done.
Resolving deltas: 100% (1073/1073), done.

Are you able to try with any other is besides CentOS? Issues like these seem to always happen with it.
It works with CentOS 7

Perhaps try running command as root, I think that go get suppresses some of the git clone errors, but unlikely.
It doesn't work though I ran command as root

Did you try and git clone the gopkg.in address? I suspect t it will fail also which means git isn't following the redirects, which is strange considering that's been working since git > 1.7 see https://github.com/spf13/hugo/issues/297
If it works on CentOS 7 it must be a CentOS 6.3 issue, maybe a firewall, security or git config setting.
I don't know how much further I can help, it doesn't seem to be an issue with the package, GitHub or gopkg.in; perhaps posting a question on Stack Overflow might yield more ideas.
It would be great to add a link from this issue to your question.

In CentOS 7, git cloning the gopkg.in doesn't works also in CentOS7.
As you mentioned, It may be a issue of GitHub or gopkg.in.
Thanks for your kind reply. :)

authors: joeybloggs laeshiny odinliu xserv

repo: go-playground/validator


text:
Fix time.Duration translation error

Fixes Or Enhances
This PR adds time.Duration translation and unit test cases.
Connected to: #1069
Make sure that you've checked the boxes below before you submit PR:

[x] Tests exist or have been written that cover this particular change.

@go-playground/validator-maintainers

coverage: 73.861% (+0.02%) from 73.843% when pulling f5e6d3664dcb0663c2b567073202f56a49e69620 on nodivbyzero:duration-translation-en-fix into 1b40ba0cb450466ab9571f5adff040b141202daa on go-playground:master.

authors: coveralls nodivbyzero


text:
router.go的鉴权使用方法错误

r.POST("/auth", api.GetAuth)改为r.GET("/auth", api.GetAuth)

r.POST("/auth", api.GetAuth)改为r.GET("/auth", api.GetAuth)

我写成 r.POST("/auth", api.GetAuth) 的时候，验证接口的得到了如下结果：
{"code":10000001,"details":["AppKey为必填字段","AppSecret为必填字段"],"msg":"passed-in parameter error"}

换成 r.GET("/auth", api.GetAuth)，验证时是：
404 page not found

可以参考我写的代码，已经对此做了修复，识别header解析的正确方法
https://github.com/golang-minibear2333/gin-blog/commit/83236bc06a13d3968f36b2c305f4f5f759f4b27b

@eddycjy

可以参考我写的代码，已经对此做了修复，识别header解析的正确方法
golang-minibear2333/gin-blog@83236bc

authors: LaChimere luhaopei minibear2333

repo: go-programming-tour-book/blog-service


text:
添加了几个模板函数，以扩充模板功能

在自定义主题中遇到了一些问题，没找到相关的函数api，我也是初入门 go template 语法，一些底层的东西了解不太深
主要有三个函数：

map
concatenate_strings
is_last

map
主要用来处理变量定义问题，在模板文件中有时需要定义一个变量结构体来传递上下文和自定义变量，比如：

concatenate_strings
主要用来处理字符串连接问题，连接一个变量和字符串字面量，比如：

is_last
主要用来判断 {{ range }} 操作是否已经枚举到了末尾，比如在数组元素中间添加分隔符：

非常感谢你的解答，问题均得到解决

map 函数可以用 dict 进行替代
concatenate_strings 函数中，经实验 printf 是可行的，但需要在字符串字面值中添加 %v 作为占位符，sprig 中内置的 cat 函数可以更加方便进行字符串变量和字符串字面值的拼接，于是采用了 cat 进行替代
is_last 函数，在 template 模板文件中存在着不能定义四则运算的问题，但 sprig 内置了可以对数字进行四则运算的函数，可以直接通过 {{ if ne $index (sub (len $context.post.Categories) 1) }}{{ end }} 进行判断是否处于数组最后一个元素位置

已经注入了一些比较常用的工具函数，使用的这个开源库：https://github.com/Masterminds/sprig
这里面提供了dict的功能，和你提供的map应该类似
concatenate_strings: 是否可以使用内置的printf来拼接呢
is_last：比较被迭代的数组的长度和index应该就能判断是否到末尾吧，go 提供了内置的 eq、lt、gt等函数

你看下是否能满足你的需求呢

非常感谢您的解答，问题均得到解决

map 函数可以直接用 dict 函数进行替代，其他语法不改变
concatenate_strings 函数可以使用内置的 printf 来拼接，但是在组合字符串字面量和变量时需要添加 %v 作为占位符，在 sprig 库中内置了 cat 函数，可以更加方便的实现字符串字面量和变量的拼接
is_last 函数，template 模板文件中并不支持四则运算，sprig 库对其进行了支持，故可以通过 {{ if ne $index (sub (len $context.post.Categories) 1) }}{{ end }} 来对数组最后一个元素进行判断

repo: go-sonic/sonic


text:
Use slippy.Grid to support tiles in different projections systems

This issue is for a design of using the new slippy.Grid in tegola, in order for it to output multiple projection systems. Implementation of this functionality would close #243, #267, and #660.
Some issues to consider for this design are:

where should the output projection system be specified? (url query string, config, command line?)
where in the code should the conversion take place? and how should the info from (1) get there?
Depending on (1) how should the cache work?

the same /:map/:layer/:z/:x/:y could have multiple tiles with different projections

(I'll post my own later this week)

Wouldn't it be simpler if tegola would simply support ONE projection per installation (or one projection per map)? If I understand correctly, upon receiving a request of tile: "scale/x/y" you have to calculate extent of the tile and use it for postgis mvt call?
You could specify tileMatrix info mentioned above in this issue in configuration file (basically extent and scale:resolutions info, tilesize) and that would be enough to calculate tile extent?

We would need this feature in order to use Tegola in our environment. I am currently evaluating vector tile servers that must meet the following requirements:

cache tiles
pre-generate tiles
PostGIS integration with custom projection (EPSG: 2056)
output tiles in a custom projection (EPSG: 2056)

The latter is crucial for us, as we operate a WebGIS with official government data, all of which is published (and maintained) in LV95 (EPSG: 2056). Our WebGIS is based on OpenLayers, which can handle EPSG: 2056 without any issues. However, it cannot handle multiple projections simultaneously—at least, to my knowledge, vector tiles cannot be reprojected on-the-fly. And even if this were possible, it would be resource-intensive and come at the cost of performance.
There are already vector tile services that allow custom projections as output, e.g., TiPg. Unfortunately, it does not support caching or pre-generating tiles.

Tegola does not support custom projections and adding them is quite the effort. While it seems fun to work on, I don’t think that any of the current active folk in the community will find the time to add it.

I understand what @callsumzg is saying, at the time the only viable option (in open source) is to use OpenLayers ant they do not allow to reproject vector tiles on the fly. So the only option is to serve local projection vector tiles. This is a problem in Lithuania too (epsg:3346).
Now if we restrict scope to have source only in MVT_PostGIS, then all of the MVT part is done by PostGIS. The only thing which has to be done is:

have a configuration of custom projection: a set of scales (resolutions) (I guess that should be enough, projection information should not be needed), something similar to WMTS configuration could be used.
ability to specify custom projection in tile configuration (say in current setting of srid)
use above mention info when calculating extent information on calling PostGIS ST_asMVT.

Would such a scope be acceptable to Tegola?
If so, would somebody be able to be a guide/mentor for such a work?

@callsumzg I think this is technically possible, but you will have to do some work to make all the pieces dance. Here's a quick example of of using the mvt_postgis provider with a 4326 projection. Note this is not exactly relevant, but demonstrates how some of the geoprocessing functions can be used to work towards your goal.
A few things to note:

If your data lives in a different projection than 3857 then you will need to reproject the incoming bbox to match your data's projection. For example in the SQL: ST_Transform(!BBOX!, 2056) or by calling ST_TileEnvelope(:z, :x, :y, :srid).
When your data is reprojected to tile coordinate space using ST_AsMVTGeom you will need to pass in the bounds made in the previous step.
The internal tegola viewer will not work as it uses maplibre for rendering which is expecting tiles in 3857 projection by default. You will need to use another renderer and define the coordinate space on the client side so it can interpret the tiles correctly.

I might be missing something, but happy to help navigate this discussion. If we land on a solid solution I would request that we get some documentation together for the future community members that need to embark on this same journey.
References:

https://github.com/go-spatial/tegola/issues/731#issuecomment-756941064
https://postgis.net/docs/ST_AsMVTGeom.html
https://postgis.net/docs/ST_TileEnvelope.html

@tomass your comment came in while I was writing mine. Take a look at my write up and see if it's helpful. I think we can accomplish this objective with the various pieces available now.

What is the reason you need the data in the origin projection? What is keeping you from reprojecting the origin geometry?

@callsumzg okay, for this purpose it makes sense.
If TipG works for you, then seeding tiles, ist just requesting tiles + storing tiles in a cache. That’s fairly simple to implement. I want to take a look at TiPG now. 👀

@iwpnd if you want to use vector tiles from tegola in OL (the only one multi-projection open webmap framework), the only way is to have your (main) map projection as 3857.
RASTER DISTORTION: This means that ALL other data sources have to be reprojected to 3857 which would not be that much of a problem with today's resolutions, but 3857 scales (or zoom levels if you wish) can be very different from local ones which does cause visual bad results when "catching" closest scale (think of pre cached WMTS). For raster the problem is distortion.
REQUIREMENT: In other cases there is a fixed requirement to have a map in local projection AND specific (non x^n) scales (but rather something imagined as 1000, 2000, 5K, 10K, 20K, 50K etc).

@tomass your comment came in while I was writing mine. Take a look at my write up and see if it's helpful. I think we can accomplish this objective with the various pieces available now.

@ARolek if I understand correctly, you make an assumption, that BBOX would return correct extent given z,x,y of a tile. But as far as I know that is not the case, because currently the calculation is for mercator. If local projection BBOX extent for zxy would be the same, then we would have no problems as coordinates in vector tiles are always [0; 4096].
In reality correct extent (bbox) calculation is the main part which would have to be developed. With BBOX calculated everything else would be easy :-) For bbox we would need some array of local projection resolutions. Something like you can find in say WMTS (something which is set up in openlayers tilegrid)
Say:
Level ID: 0 Resolution: 1322.9193125052918 (Scale: 5000000)
Level ID: 1 Resolution: 793.7515875031751 (Scale: 3000000)
Level ID: 2 Resolution: 529.1677250021168 (Scale: 2000000)
etc.
And then you would use resolution with zxy to calculate actual extent of a tile.
Years ago I've written some demo code to explain tile extent calculations, don't know if they are correct but results looked ok :-)
So given resolution array (for 4 zoom levels)
res float[] = ARRAY[2.6458386250105836,  -- 0
                    1.3229193125052918,  -- 1
                    0.5291677250021167,  -- 2
                    0.26458386250105836  -- 3
                   ];

Tile size, origin x and origin y:
c_tilesize int = 512;
c_origin_x float = 307558.9491752772;
c_origin_y float = 6264605.2051798785;

I wold then calculate tile geometry (so tile extent) for given
l_tile_geom = st_setsrid(st_makepolygon(st_geomfromtext('LINESTRING(' ||
  (x       * res[z] * c_tilesize) + c_origin_x || ' ' || c_origin_y - (y       * res[z] * c_tilesize) || ',' ||
  ((x + 1) * res[z] * c_tilesize) + c_origin_x || ' ' || c_origin_y - (y       * res[z] * c_tilesize) || ',' ||
  ((x + 1) * res[z] * c_tilesize) + c_origin_x || ' ' || c_origin_y - ((y + 1) * res[z] * c_tilesize) || ',' ||
  (x       * res[z] * c_tilesize) + c_origin_x || ' ' || c_origin_y - ((y + 1) * res[z] * c_tilesize) || ',' ||
  (x       * res[z] * c_tilesize) + c_origin_x || ' ' || c_origin_y - (y       * res[z] * c_tilesize) ||
  ')')), 3346);

And this geometry is the BBOX for specific local projection.
Basically we have a cartesian space [x;y] in local projection, so we have some "starting" point for tiles as defined by origin x and origin y variables (this is used when for one reason or another an area around 0;0 is not actually used for data). We would then divide the space from origin point using zoom levels resolution and tile size.

So configurations for all above numbers for projections would have to go somewhere (or they could probably come from projection info).

Wait... but we could simply change sql from:
sql = "SELECT ST_AsMVTGeom(geom,!BBOX!) AS geom, gid FROM gis.landuse WHERE geom && !BBOX!"
to:
sql = "SELECT ST_AsMVTGeom(geom,calculate_my_projection_bbox(!z!,!x!,!y!)) AS geom, gid FROM gis.landuse WHERE geom && calculate_my_projection_bbox(!z!,!x!,!y!)"
In that case the only thing we need is a database function calculate_my_projection_bbox(!z!,!x!,!y!)... and it should work.

Played a little bit around it and in principle it works (orange vector tile from tegola is depicted on a 3346 WMTS layer)

What have I done:

in OpenLayers defined TileGrid in order for local WMTS to work as it does use local scales (I would have to do it anyway, independent of vector tiles)
created a database function as per my code above with the resolutions as in TileGrid
changed sql in tegola configuration to use this function instead of !BBOX! both when calling ST_AsMVTGeom as well as in WHERE clause.

What I've found/encountered

!BBOX! is mandatory, so I've added a pointless "and !BBOX! is not null" in WHERE clause
not all X/Y values are ok, tegola complains about Y of > 400 and Y ~15 - had to use origin: [0,6500000] in OL tilegrid and then use the same origin in db function (this allows me to kind of control the XY values, but is not a good solution as it will probably not work in all required "places").

My questions:

Where does validation of XY come from and what is it trying to do?
Would it be a wanted addition to tegola? It looks like it would only require to extend functionality of !BBOX! calculation using origin point and an array of resolutions.

@tomass thanks for sharing your research! This is great news as it sounds like most of the pieces are available to make this work. Let me answer some of your questions and then I have a few more for you.

Where does validation of XY come from and what is it trying to do?

I believe this is in the geom package's slippy package under the method Extent. This package relies on the proj package which might need to be extended to account for various SRIDs.
https://github.com/go-spatial/geom/blob/55e666d67bc5969a5f2e09b17185f72727e5f0f9/slippy/tile_grid.go#L48

Would it be a wanted addition to tegola? It looks like it would only require to extend functionality of !BBOX! calculation using origin point and an array of resolutions.

Ideally the geom package would be able to support different projections like you're exploring here. I'm not familiar enough with projection math to make these enhancements. Is this in your wheelhouse? If so, it would be a fantastic addition.

!BBOX! is mandatory, so I've added a pointless "and !BBOX! is not null" in WHERE clause

Hmm, that's annoying. We should check for the use of !BBOX! or !Z! !X! !Y!
A couple of follow up questions:
Did you have to implement a custom calculate_my_projection_bbox(!z!,!x!,!y!) function? I figured you could accomplish this 2 ways:
ST_Transform(ST_TileEnvelope(!Z!, !X!, !Y!), :YOUR_TARGET_SRID)

Or alternatively, the ST_TileEnvelope() function supports an optional bounds
ST_TileEnvelope(!Z!, !X!, !Y!, :YOUR_BOUNDS)

The documentation defines the bounds as:

The optional bounds parameter can be used to generate tiles in any coordinate system. It is a geometry that has the SRID and extent of the "Zoom Level zero" square within which the XYZ tile system is inscribed.

You mentioned using this custom function when calling ST_AsMVTGeom:

changed sql in tegola configuration to use this function instead of !BBOX! both when calling ST_AsMVTGeom as well as in WHERE clause.

You should be able to use the same ST_TileEnvelope() strategy above to pass in the geom to ST_AsMVTGeom. This would allow you to use only native PostGIS functions to achieve your desired outcome around querying and tile forming. Could you give this a try?

@ARolek thank you for information, here are my further thoughts.

Ideally the geom package would be able to support different projections
like you're exploring here. I'm not familiar enough with projection math to
make these enhancements. Is this in your wheelhouse? If so, it would be
a fantastic addition.

There is no need to do any projection math here ;-) All heavylifting is done by PostGIS MVT functions.
We only need to calculate BBOX correctly.
If we could come up with a good/acceptable way of adding all required parts into configuration, I might be able to do the PR with some guidance.
It would be simple, if it would be possible to reuse the SRIS configuration option like this:
SRID=###,[scale0resolution, scale1resolution, ...]
for example:
SRID=3346,[793.7515875,529.167725,264.583862,132.291931]
This would be all what has to be done in configuration to get custom projection tiles.
But SRID is already used somehow, Tegola is currently trying to transform data from specified SRID to 4326/3857, right?

!BBOX! is mandatory, so I've added a pointless "and !BBOX! is not null" in WHERE clause

Hmm, that's annoying. We should check for the use of !BBOX! or !Z! !X! !Y!

If Tegola would support other projections this validation should stay as it is very useful, sql without the BBOX might cause some serious overwork.

Did you have to implement a custom calculate_my_projection_bbox(!z!,!x!,!y!)
function? I figured you could accomplish this 2 ways:
...

ST_TileEnvelope is very close to what is required, but at least in my case difference is not only in projection, but in scales as well. Mercator scales are calculated mathematically while in my case scales come from some old "tradition" and n+1 scale is not simple multiplication of previous one by 2. So without being able to specify all scales (resolutions for all scales) it is impossible to calculate the BBOX/Envelope simply by having zxy.
I wonder how is it in @callsumzg case? Do you have some custom scales as well? Or are scale resolutions the same as for Mercator?
Real scale resolutions:
793.7515875031751,
529.1677250021168, <--- diff from previous one 0,66
264.5838625010584, <-- diff from previous one 0,5
132.2919312505292, <-- diff from previous one 0,5
66.1459656252646, <-- diff from previous one 0,5
26.458386250105836, <-- diff from previous one 0,39
This allows to have scales which resemble "old school" ones like 1:5000, 1:10000, 1:25000 (note the jump here is not x2), 1:50000 etc.
Specifying scale resolutions is not something strange or new, it is a standard thing in say WMTS GetCapabilities.

Just for the record, if somebody has an answer or somebody later gets the same question.
I've thought about a variant where mercator scales would be used and thus standard st_tileenvelope could be used. Unfortunately the way st_tileenvelope works is you provide some square which will be your 0 scale tile. Then 1 scale would be 0 scale divided to four equal tiles and the same principal further.
This is completely different from what is done in OpenLayers where we have tile size - say 512 and when resolution - size of one pixel. If resolution is 0.5 when tile size is 256 meters x 256 meters. So our first tile is from 0,0 to 256,256 meters.
Therefore I do not currently see a nice way to "convert" from resolution way of calculating tiles (which is used in OL) to simple division used by PostGIS. In my understanding most projections would be "impossible" on mercator zoom 0. But I might be wrong here.

authors: ARolek callsumzg ear7h iwpnd tomass

repo: go-spatial/tegola


text:
Shutdown method on server do not close the server

Problem statement
When generating a server implementation and calling Server.Shutdown method from restapi package the server is not actually closed though the documentation states Shutdown server and clean up resources. Only the API.ServerShutdown callback from operations package is called but the actual server is not closed.
The graceful server exposes the API needed to shut it down gracefully but the generated abstraction does not allow access to this API. Because of this, only an OS signal can kill the graceful server when running the generated server.
I propose to expand the Server.Shutdown method to signal the graceful server to initiate a shutdown. It is a fairly simple addition to the API and I'm happy to make a PR with the changes.
When looking over the source the following changes are necessary:

Server.Serve should listen for on a shutdown channel and stop the graceful server when receiving a signal
Server.Shutdown should send a signal on the shutdown channel
Code on examples should be updated to hold the new implementation

Steps to reproduce
A slightly modified version of the custom-server tutorial example shows the behaviour. After 5 seconds the server is instructed to shut down by calling Shutdown. The ServerShutdown callback is called but the server continuous to run.
When running the output is as follows. Not that I manually interrupt the server with CTRL + C.
$ go run ./cmd/greeter/main.go --port 3000
2017/12/08 14:03:39 Serving greeter at http://[::]:3000
2017/12/08 14:03:44 api shutdown called
^C2017/12/08 14:03:53 shutdown initiated
2017/12/08 14:03:53 Stopped serving greeter at http://[::]:3000

Below is a stripped snippet from the main.go.
// from  examples/tutorials/custom-server/cmd/greeter/main.go

// create new service API
api := operations.NewGreeterAPI(swaggerSpec)
api.ServerShutdown = func() { log.Println("api shutdown called") } // added
server := restapi.NewServer(api)

// parse flags
flag.Parse()
// set the port this service will be run on
server.Port = *portFlag

// GetGreetingHandler greets the given name,
// in case the name is not given, it will default to World
api.GetGreetingHandler = operations.GetGreetingHandlerFunc(
	func(params operations.GetGreetingParams) middleware.Responder {
		// ...
	})

// added
go func() {
	time.Sleep(5 * time.Second)
	server.Shutdown()
}()

// serve API

@casualjim Would you be interested in this PR?
I belive this is more of a bug fix than an enhancement as the generated documentation describes that the server should shutdown after a call to Server.Shutdown() but it does not?

My own feeling is that all contributions are welcome.
You should not worry that much about bug vs enhancement distinction in issues.
It is more an indication on how to priorize things.
Since the toolkit has many use cases it is often difficult to judge priority from a single userr's perspective.
Generally speaking if you feel it is important, post a PR.

The reason I'm asking is to prioritise my time as well. We are using this in production now and would like to know if a PR is likely to be released any time soon.
Any how, I'll prepare a PR. Any checklists or alike I should use? I had some difficulty running the different make targets locally. Is it fine to just make the changes in the templates and sources and let example generation etc. be handled when things are to be merged?

yes I think this is a valuable contribution. I have to see exactly where the changes will be made and at worst I'd ask to rename a method or something.

if you can run go test ./... we should be good

Great. I'll prepare the PR. Thank you for the quick answers.

authors: Crevil casualjim fredbi

repo: go-swagger/go-swagger


text:
adjacency list or parent-child tree

Perhaps someone can assist, I couldn't find what I'm looking for in the documentation or the tests.
I have one struct:
type Node struct {
	Id       int64 `xorm:"pk autoincr"`
	ParentId int64
	Parent   *Node `xorm:"node_id BIGINT"`
        //Children []*Node `xorm:"node_id BIGINT"`
}

each node can be attached to other nodes as parent or child; the parent part seems to work here, but I cannot determine how to get a slice of *Nodes. I am guessing I'll need to write something like:
func (n *Node) getChildren  (s *xorm.Session) []*Node {
    var nodes []*Node
    err := s.Where("parent_id" == n.Id).Find(&nodes)
    return nodes
}

but the point is I'm having difficulty about how to catalog & gather relations 1-to-1 seems to work, but I'm having difficulty seeing other relations in the documentation or code, yet.

Hi, currently we haven't provide 1-to-N, only 1-to-1. And we encourage you to use join instead relations, you can find the manual on gobook, and find join section on How to use join.

ok

authors: lunny thrisp

repo: go-xorm/xorm


text:
Discord Server

Hi, I am really interested with the development of this and I want you guys also make a discord server as slack is limited and you can easily enjoy discord open source benefits.

Hello @Delta456, thanks for the suggestion! And I just created a server today, you can join it with this link https://discord.gg/SS5HbYN

Amazing! It will be good to add this link to README.md as people who are interested can join the server. @st0012

@Delta456 thanks for the suggestion, I've added it yesterday. Going to close this issue now 😄

repo: goby-lang/goby