Comment by shdh | Hacker News Reader

Comment by shdh | Hacker News Reader

Parent Full thread

> The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages,

I agree with this, they need to do a better job of updated those circular indicators.

> the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild,

Not sure when you last used their CI, but I've never experienced this issue.

> the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit.

A tag created through the GitLab web GUI is directly connected to `git tag`

> It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal.

I think you should refer to the manual.

* https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplifi... * https://docs.gitlab.com/ee/ci/yaml/#when * https://docs.gitlab.com/ee/ci/variables/

> A tag created through the GitLab web GUI is directly connected to `git tag`

It appears you may be suffering from the same confusion (or perhaps you're not aware of the feature), I'm talking specifically about gitlab-ci tags https://docs.gitlab.com/ee/ci/yaml/#tags

That has nothing to do with git tags, but one could be forgiven for believing that's the case when the documentation exacerbates this confusion. From the docs you just linked

> only defines the names of branches and tags for which the job will run

"tags" in that sentence has nothing to do with git tags but is actually referencing a gitlab-specific job tagging feature. It's very confusing.

> I think you should refer to the manual.

I have. The tools provided are not sufficient to accomplish the examples I have described. I'm happy to be proven wrong because it'd actually be quite useful to me. Can you direct me to how I might trigger a job only on tagged commits pushed to the master branch?

As far as when/except/only etc, they are not able to introspect on variables or conditions within the context of the job runner, they can only react to gitlab-specific signals like the success or failure of other jobs, I can't do something like "build, run unit tests, run eslint, run flow type checker, deploy but only if nothing else failed, except eslint which is only a soft requirement but not a deployment blocker". Any failure in one job is a failure for all jobs unless you make it explicitly the inverse which still doesn't give you intelligent control over the jobs.

> > It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time...

> I think you should refer to the manual.

GP is correct - there is no way to do it. Workarounds posted on multiple issues simply don't work. Official docs are vague on the matter, but the fact is, GitLab doesn't support this common scenario. And a few others either while we're at it... Like allowing me to schedule a manual job for when dependencies finish. I have to wait every time and it's annoying as hell.

Reply on news.ycombinator.com