8.6 CI Features

Added ~19173 label

Milestone changed to 8.6

@ayufan Shouldn't the "artifacts for failed builds" #4034 (closed) be a planned feature?

This is really needed by many developers.

@mablae We try as hard as possible to do everything in one release, but we do have a limited capacity to implement actual features and fix bugs :) The future features can be grabbed by anyone, it fits in our roadmap and we want this feature to be implemented in GitLab.

Hi guys, additionally, it would be awesome, if we could have a task or a way (gui view?) to cleanup builds that are finished.

Here where I work, we use CI to do CD using the ability to gitlab-ci to call external binaries (Bash/Binaries/Others).

We do deploy a bunch of branches dynamically using this process but then our storage capacity is decreasing dramatically.

Of course, I have created a shell script which allow me to make a regular cleanup on deprecated branches (using cron and our APIs), but it would be wonderful if my Gitlab's users could directly erase their own build once they've finish their test/show by clicking on the erase button which then would call the cleanup step of the build.

I'm writing this request here rather than opening a new issue as it's not an issue but rather a request for improvement and that @ayufan already made a list of future features improvements

@gtherond Please create an separate issue for feature. This is only way when we can have discussion about that feature and not clutter the thread where the is progress for specific milestone.

mentioned in issue #13609 (closed)

mentioned in issue #13982 (closed)

looks like this one #3423 (closed) is missing on the list?

@ayufan Ok, I'll open another issue regarding my needs ;-) thx.

@ayufan Do you know how you're going to implement the fix for gitlab-org/gitlab-ci#224? I'm interested in being able to clone submodules without needing to set up boilerplate code in .gitlab-ci.yml. Perhaps if the project has a variable like CI_SSH_PRIVATE_KEY set in it, gitlab-runner would change to use the SSH protocol instead using the specified key? And then, assuming that said key was set up as a deploy key for all submodules, gitlab-runner could use the --recursive flag in its git clone command (and likewise for the git fetch path).

@jasonroehm Not sure yet, sorry.

@jangorecki Added

@ayufan "Testing dependent projects (git submodule problem)" is listed as blocked by something else. What's the blocker at present? I understand that there are some issues to work out with exactly how it could work. Would the strategy that I proposed a couple messages up be reasonable? I may try to contribute a MR if so.

@jasonroehm

I would prefer to continue using the https cloning. We could allow the build token to clone also other projects. We need to workout details how we will define dependent projects. Maybe simple option to add a dependent projects in GitLab UI would work? We could add a dependent CI projects, or just analyze the .gitsubmodules?

At least for now the git submodule update --init would still need to be executed by user.

As for the SSH key - we planning to introduce the plugin system, one of the plugin system features would be ability to define credentials. One of the credentials would be the SSH key which would be handled by runner.

mentioned in issue #14373 (closed)

Milestone changed to 8.7

Milestone changed to 8.6

Issue for 8.7: https://gitlab.com/gitlab-org/gitlab-ce/issues/14717

Status changed to closed

8.6 CI Features

Designs

Child items ...

Activity

Admin message

Admin message

8.6 CI Features

Activity