This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency urllib3 to v1.26.18 [SECURITY]
• Update dependency idna to v3.7 [SECURITY]
• Update dependency certifi to v2023 [SECURITY]
• Update dependency click to v8.1.7
• Update dependency charset-normalizer to v3.3.2
• Update dependency python-gitlab to v3.15.0
• Update actions/checkout action to v4
• Update actions/setup-python action to v5
• Update dependency python-gitlab to v4
• Update dependency requests-toolbelt to v1
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Symptoms

If I try to list my personal GitLab projects, e.g.

concierge-cli gitlab topics bittner/

or

concierge-cli gitlab mrs bittner/

then nothing is listed, even though I have several projects at https://gitlab.com/bittner/.

Explanation

The current implementation (Topicmanager, MergeRequestManager) loops over a list of groups to make easy filtering of groups and projects possible. It looks like the personal namespace is not considered as a Group for a GroupProject in in the GitLab API.

How to fix this?

If you think this is a problem that deserves fixing, please

1. investigate the issue on the GitLab issue tracker first, and review the python-gitlab docs and related GitLab API docs
2. comment here for a proposed solution
3. create a PR to fix the implementation

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

Due to GitLab's API design the CLI makes a lot of separate queries, which slows down the execution time. This is typically at least O(n ²) time due to nested loops combined with general slowness as API calls to an external service are performed each time.

This can most probably not be fixed via algorithmic changes, but requires parallelization. We may tackle this using Python's asyncio module. See the recording of Michael Kennedy's webinar for a good intro.

Some of the tests for the manager module and the adapter module need to be properly implemented.

The implementation idea is in place, but mocking the remote API appropriately is needed. -- Look for the commented out sections and the TODO: comments!

GitLab 13.0 introduces breaking changes to the groups API endpoint.

This is likely to affect us, as we get the projects from the groups for the projects CLI command.

Currently, the concierge-cli projects command allows to specify several --topic options to select all projects that match any of those values (i.e. the possible topic values are logically OR'ed).

Needed Features

• It should be possible to alternatively specify several topics, which are the locally AND'ed to select only projects that have all of those topics set (as a subset).
• Aligned with that, it should be possible to set the topics with the same topics syntax (in addition to using several --set-topic options)

Examples

concierge-cli gitlab projects --topic managed,waf,group::foobar
- mygroup/my-project-one
- another/my-project-two

concierge-cli gitlab topics /my-project- --set-topic one,two,three

With our current release process we need to push a tag to all repositories we bulk-manage. On the GitLab Web frontend this is a bit time-consuming, and actually error-prone (you can easily overlook repositories).

On the command line we could easily do that quicker using just git, but we'd need to close every single repository. We should probably better do that via GitLab API calls.

Given that we'll release frequently and more in terms of "reflect the current state of are" (not in terms of release "features of a product") semver is likely less suitable as a versioning scheme than something that better reflects both a date/time "bandwidth" of release activities and blends in well in automated operations (e.g. increment last number when several releases need to be done). This might be a date-based scheme, e.g. YYYY.MM.c with c being a monthly release counter starting at 1 each month (or YY.MM.c like Ubuntu does it). EDIT: (see explanation below)

Needed Features

• List latest tag(s) of a number of repository (e.g. project filtered by --topics), detecting whether there are unreleased commits
• Set a tag on a number of repositories (as listed earlier)

Examples

(See comment below)

Currently, we have to specify the --token value as a CLI option for the gitlab command. That's not nice if we want to do, say, screen sharing in a video conference session.

It would be helpful if it we possible to specify the token only once by exporting an environment variable, e.g.

$ export CONCIERGE_GITLAB_TOKEN=jflsalgaslgkh
$ concierge-cli gitlab groups example-user
...

Similar for the --uri option, probably. This could be covered by CONCIERGE_GITLAB_URI, so a user wouldn't need to create a configuration file.