| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is confusing to have a `gitlab/__version__.py` because we also
create a variable `gitlab.__version__` which can conflict with
`gitlab/__version__.py`.
For example in `gitlab/const.py` we have to know that
`gitlab.__version__` is a module and not the variable due to the
ordering of imports. But in most other usage `gitlab.__version__` is a
version string.
To reduce confusion make the name of the version file
`gitlab/_version.py`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are planning on adding enumerated constants into gitlab/const.py,
but if we do that than they will end up being added to the top-level
gitlab namespace. We really want to get users to start using
`gitlab.const.` to access the constant values in the future.
Add the currently defined constants to a list that should not change.
Use a module level __getattr__ function so that we can deprecate
access to the top-level constants.
Add a unit test which verifies we generate a warning when accessing
the top-level constants.
|
| |
|
|
|
|
|
| |
BREAKING CHANGE: remove deprecated constants defined in
gitlab.v4.objects, and use only gitlab.const module
|
|
|
|
|
| |
BREAKING CHANGE: python-gitlab will now default to gitlab.com
if no URL is given
|
|
|
|
|
|
| |
Fix the import ordering using isort.
https://pycqa.github.io/isort/
|
| |
|
| |
|
|
|
|
|
|
| |
A "minimal access" access level was
[introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/220203) in
GitLab 13.5.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This constant is useful for cases where no access is granted,
e.g. when creating a protected branch.
The `NO_ACCESS` const corresponds to the definition in
https://docs.gitlab.com/ee/api/protected_branches.html
|
| |
|
|
|
|
|
|
|
| |
to MAINTAINER_ACCESS to follow GitLab 11.0 docs
See:
https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions
|
| |
|
| |
|
|
|