[Meta] Improve time-to-first-green-build

Meta issue to track ideas for improving onboarding or getting started with CI/CD pipelines, so people get their first (green) build as quickly as possible.

Ideas:

• Detect language and suggest .gitlab-ci.yml for them (building on existing templates)
• Detect installed components/frameworks and suggest custom .gitlab-ci.yml for their specific tests
• Wizard/GUI for creating .gitlab-ci.yml
• Run CI Linter when submitting .gitlab-ci.yml changes
• CI Lint in file-tree view of .gitlab-ci.yml
• (Better) tutorials
• Improve instructions for install runners
• Move autoscaler into GitLab process to remove need for first runner
• Leverage tightly integrated container scheduler or IaaS credentials to create new runners with reasonable defaults
• Let people run CI/CD on the GitLab instance (not advised, but might get people started faster)
• Issues from #21624 (moved) which improve non-cached, initial runs (such as preloading runner image with common tools)

Links

• Related to #21624 (moved)

mentioned in issue #21624 (moved)

Detect language and suggest .gitlab-ci.yml for them (building on existing templates)

We did detect the language but this was too compute intensive, so we've removed that feature. Maybe we could get that back? But still, a language can be Ruby, while the framework is Rails. I see some complications here, but al in all seems doable.

Run CI Linter when submitting .gitlab-ci.yml changes

Related (somewhat): https://gitlab.com/gitlab-org/gitlab-ce/issues/13448

That said, I think, probably like you, this is important, and we might want to consider taking one of these and put them in the CI Plan each release.

Thanks @zj. Updated description a bit.

Probably a bad idea, but still. To get an idea of how CI works I just had someone create a .gitlab-ci.yml on an empty project containing:

test:
  stage: test
  script:
    - exit

This gave the user a green build to iterate on: include a Makefile and replace exit with 'make'. etc etc. I've not yet had further feedback, but I could imagine the starting point of a green build is better to iterate on than trying too much on the first build so you don't actually know why it just failed..

@zj You know, that's not a bad idea. Especially since there's work get runners working first, having a no-op CI configuration might in fact help people get started so they're only debugging one thing at a time. I could at least see this as a tutorial step, if not an actual template to start with.

circleci Infers a lot, such as language. I dont necessarily like it or find it valuable. Sometimes the magic is unexpected. I have node projects that use Make and am working on a suite of Terraform modules what will use NPM. I think most of the inference ends up overwritten.

@zj akin to ttd. i like it.

The rest of @markpundsack's list sounds pretty interesting to me.

I would also like to be able to troubleshoot an individual job without invoking the entire pipeline. circleci allows an option to try gain with ssh...

Another thing that I htink would short time to green is to trim whitespace from env vars #22898 (moved)

mentioned in issue #27953 (moved)

moved to gitlab#6062

Hey!

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:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

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.

locked this issue