4 ms·

As a paying gitlab ee customer, we love to use gitlab. I just have one gripe with review apps. We would really like you to open it up with an API. Allowing us

by wernerb 10y ago

As a paying gitlab ee customer, we love to use gitlab. I just have one gripe with review apps. We would really like you to open it up with an API. Allowing us to create the infrastructure outside of gitlab-ci and setting the reviewapp url/domain etc using the API would be extremely valueable for us, as we are stepping off of the gitlab-ci, but would very much like the UI interface upgrades review apps provides. We are stepping off of Gitlab CI because of: * Only a single pipeline allowed per repository. We have a monorepo as we have a lot of small artifacts that make no sense to split out to multiple repo's and have to manage using gitsubmodules or having a separate code review process (we use merge requests a lot!) * Gitlab-ci's "stages" and not allowing dependencies on cross-stage is not helpful * No "skipped" status that can be supplied during the pipeline. E.g., we want to ignore changes to our documentation .

sytse 10y ago
If you have specific functionality that is now only in the interface in an API we'd be glad to have a look. But it sounds like you want to replace functionality in .gitlab-ci.yml with an API, this would be hard. Instead we would gladly word with you to make GitLab CI better so you can keep using it. 1. Single pipeline => I understand using a monorepo. But I don't understand yet why you need multiple pipelines. Does the pipeline work different depending on what file is updated? 2. Do you mean cross project pipelines? https://gitlab.com/gitlab-org/gitlab-ee/issues/933 https://gitlab.com/gitlab-org/gitlab-ee/issues/933 3. Do you mean setting criteria for build skipping in .gitlab-ci.yml ? What would be an example criteria? Since you are a paying customer feel free to work with our support team to have the features you need prioritized. We want everyone to be able to use GitLab CI.
grzesiekb 10y ago
Thanks for this feedback! At GitLab, we believe that work is never done, and we are always looking for things we can improve, in our CI solution as well! Let me address some of your concerns: 1. There is only one pipeline allowed at the moment (see issue about support for multiple pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/22972 https://gitlab.com/gitlab-org/gitlab-ce/issues/22972), but you can use multiple builds / stages to usually achieve the same. We also plan to add ability to control status using exist code from the build (see https://gitlab.com/gitlab-org/gitlab-ce/issues/25738 https://gitlab.com/gitlab-org/gitlab-ce/issues/25738). You can also use our pipeline trigger API with environment variables to control what get executed. 2. That is true, we already did some backstage work to improve that. In the meantime it is possible to explicitly depend on builds from the previous stages to download all artifacts in subsequent jobs. 3. I'm not sure if I understand correctly, what you want to accomplish, but if `[ci skip]` is not enough, then status based on the exit code may be helpful as well.

by wernerb 10y ago

sytse 10y ago

If you have specific functionality that is now only in the interface in an API we'd be glad to have a look. But it sounds like you want to replace functionality in .gitlab-ci.yml with an API, this would be hard. Instead we would gladly word with you to make GitLab CI better so you can keep using it. 1. Single pipeline => I understand using a monorepo. But I don't understand yet why you need multiple pipelines. Does the pipeline work different depending on what file is updated? 2. Do you mean cross project pipelines? https://gitlab.com/gitlab-org/gitlab-ee/issues/933 https://gitlab.com/gitlab-org/gitlab-ee/issues/933 3. Do you mean setting criteria for build skipping in .gitlab-ci.yml ? What would be an example criteria? Since you are a paying customer feel free to work with our support team to have the features you need prioritized. We want everyone to be able to use GitLab CI.

grzesiekb 10y ago

Thanks for this feedback! At GitLab, we believe that work is never done, and we are always looking for things we can improve, in our CI solution as well! Let me address some of your concerns: 1. There is only one pipeline allowed at the moment (see issue about support for multiple pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/22972 https://gitlab.com/gitlab-org/gitlab-ce/issues/22972), but you can use multiple builds / stages to usually achieve the same. We also plan to add ability to control status using exist code from the build (see https://gitlab.com/gitlab-org/gitlab-ce/issues/25738 https://gitlab.com/gitlab-org/gitlab-ce/issues/25738). You can also use our pipeline trigger API with environment variables to control what get executed. 2. That is true, we already did some backstage work to improve that. In the meantime it is possible to explicitly depend on builds from the previous stages to download all artifacts in subsequent jobs. 3. I'm not sure if I understand correctly, what you want to accomplish, but if `[ci skip]` is not enough, then status based on the exit code may be helpful as well.