• Gitea version (or commit ref): 1.13.2 built with GNU Make 4.3, go1.15.7 : bindata, timetzdata, sqlite, sqlite_unlock_notify
• Git version: 2.26.2
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
• Log gist:

Description

Pleas

This package could be used to enhance the readability of a lot of our tests:
https://github.com/JamieMason/expect-more/tree/master/packages/expect-more-jest/

Description of the problem, including code/CLI snippet

Documentation is missing an example how to make use of project import parameters.
The Gitlab-API supports these parameters (name,file,path,overwrite)

Expected Behavior

It would be good to add an example to the documentation (if those parameters are supported)

Actual Behavior

Specifications

• python-gitlab versi

Is your feature request related to a problem? Please describe.
GitLab's API has support for importing repositories from GitHub and Bitbucket to GitLab.
It would be a nice-to-have feature in glab.

Describe the solution you'd like
glab should provide a sub-command for the repo command that helps users import repos from GitHub and Bitbucket to GitLab.

glab repo import <ho

#197 took care of being able to use # at the start of a line, but I just noticed that there isn't a great user flow for editing an issue that already has markdown headings.

1. Create an issue with at least 1 heading
2. Edit the issue with lab issue edit [ID]
3. Make changes and save
4. The issue will now have its heading(s) stripped out

I'm not sure what the best course would be, but

Currently if you try to clone a repository from github and you don't have any ssh keys configured at github, you will fail to clone and get such message:

Fatal error: fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Even Permission denied (publickey). message is not shown.

@guyzmo offered to "suggest a

Scalafix commits are currently attributed in the Git history to the Scala Steward user although it only did the easy part of running the rule. The hard part of writing the rule is done by someone else who's currently not attributed in any way. Wouldn't it be nice if we append Co-authored-by attributions to the Scalafix commit if the rule author(s) opts into i

https://github.com/google/starlark-go/blob/master/doc/spec.md

It should satisfy our reproducibility needs (like jsonnet) and could be easier to write agola config files.

Like in #137 we should provide build context information.