Skip to content
Snippets Groups Projects
New issue look: Off

"Pipeline failed" error in forks of projects with specific runners

    • Closed (moved) Issue created by username-removed-25943 @ralf

    Summary

    We have a project with some specific runner that is used to measure timing regressions. This takes lots of resources as we need to reserve all cores of one socket for one job to avoid interference between timing measurements of concurrently running jobs. Hence we don't want these runners to be assigned to forks of the project that external contributors work on. As a consequence of this, external contributors get error messages in the web UI after pushing (about no runners being available), and one day later, they get an entirely uninformative email saying "pipeline failed" with a link to a build page that shows an empty log.

    Steps to reproduce

    Have a project with some specific runners and a CI job that has a tag only provided by these runners. Set things up so that forked projects do not inherit the runners. Fork the project. Push something to the fork.

    What is the current bug behavior?

    There are errors shown in the web UI about missing runners. Furthermore, after one day (probably the CI job timeout), there is an email saying "pipeline failed" and not saying anything else. This is very confusing for external contributors that make a fork to create merge requests for things to be merged back into the main project.

    What is the expected correct behavior?

    Ideally, there should be no errors whatsoever even though the project has a .gitlab-ci.yml and no runners. This could be conditioned on it being a fork. At the very least, there should be no errors, but just warnings (and no emails) indicating that the jobs are all stuck.

    Relevant logs and/or screenshots

    Here's how the build page of such a failed build looks like: Spectacle.Zb9299

    Further information

    This is with GitLab Community Edition 8.16.4 (f32ee822).

    Designs

      Child items ...

      2. Activity

      • Grzegorz Bizon
        Grzegorz Bizon @grzesiek ·
        Maintainer

        @ralf Thanks for the report! I agree that there is some room for improvement here. The only information we show currently is "stuck" label that is added to jobs when there are no runners available. Later, after 24 hours the CI job is canceled.

        @dimitrieh would it make sense to make information about no available runners more visible?

      • Grzegorz Bizon added ~19173 ~19492 feature proposal labels

        added ~19173 ~19492 feature proposal labels

      • Grzegorz Bizon
        Grzegorz Bizon @grzesiek ·
        Maintainer

        Also related to https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        @grzesiek yes... mmh isn't this currently not already shown with a banner or something?

        @hazelyang there may be an opportunity here for an empty state, what do you think?

      • Hazel Yang
        Hazel Yang @hazelyang ·
        Developer

        @dimitrieh Agree. An empty state explains the situation would be helpful for the users.

      • username-removed-25943
        username-removed-25943 @ralf ·
        Author

        A "stuck" label is shown after pushing a commit, but after 24h (after the mail was sent), the label disappears.

        Indeed #23902 (moved) is related at least insofar as we'd also like to have CI on merge requests -- but seamlessly not having CI on forks feels like a somewhat independent problem.

        Edited by username-removed-25943
      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        @grzesiek i think i misunderstood what was asked precisely. I was thinking of this error message:

        image

        it seems that after a certain period, even if a build is still stuck, it just fails the pipelines.. correct @ralf ?

        the requested result would be that they would stay stuck and not default to failed after X period?

      • username-removed-25943
        username-removed-25943 @ralf ·
        Author

        it seems that after a certain period, even if a build is still stuck, it just fails the pipelines.. correct @ralf ?

        That's what it does, correct.

        the requested result would be that they would stay stuck and not default to failed after X period?

        That, or maybe give up in some other form. For example, having that "pending" icon next to all commits will probably also be irritating for people. Ideally, for a fork without runners, it would behave exactly as if the .gitlab-ci.yml was not present.

      • Grzegorz Bizon
        Grzegorz Bizon @grzesiek ·
        Maintainer

        I think that behaving like there is no .gitlab-ci.yml would be even more confusing. I was thinking about adding a warning message on pipelines page.

      • Felipe Artur moved to gitlab#8388

        moved to gitlab#8388

      • Felipe Artur
        Felipe Artur @felipe_artur ·
        Maintainer

        Hey! :wave:

        GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

        If you have any questions about all of this, please ask them in our dedicated FAQ issue.

        https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

        You can also find more information here:

        Frequently Asked Questions

        For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

        What will we do with the repository names?

        https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

        Why rename gitlab-ce to gitlab-foss?

        Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

        I created a merge requests for CE, and this got closed. What do I need to do?

        You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

        How does the licensing work in this new setup?

        Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

        Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

        No. Merge requests submitted to this project will be closed automatically.

        Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

        Yes.

        How will this affect users of GitLab CE using Omnibus?

        No changes will be necessary, as the packages built remain the same.

        How will this affect users of GitLab CE that build from source?

        Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

        Where can I see a timeline of the remaining steps?

        https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

        Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

        Yes, these changes will be synced to gitlab-foss automatically, several times per day.

      • Felipe Artur locked this issue

        locked this issue

      Please register or sign in to reply