For the MVC of the directed acyclic graph, we're lacking support for defining an empty needs: array to specify that something has no predecessor. If we supported this, users could mark a job in a second or beyond stage as eligible to start immediately.
Intended users
Individual contributor automation engineers
Further details
Consider the following yaml which has a build, setup_test_env, and test job:
With this new keyword, we could allow setup_test_env as follows to allow it to run as soon as the pipeline starts, but still appear in the test stage where it makes more logical sense:
setup_test_env:stage:testneeds:[]
Proposal
Allow for needs: [] which will indicate to GitLab that a job, regardless of what stage it's in, can always start immediately.
Permissions and Security
N/A
Documentation
Testing
What does success look like, and how can we measure that?
This is really valuable for Auto DevOps as the test job can be started straight away but for aesthetic reasons it needs to be in the second stage (called test). It would be weird if our test job was in the build stage. As such it would be great if we could just add needs: [] to the test job and this would have another flow on affect after adding needs: [test] to the production job that basically we would substantially cut down on total pipeline times for Auto DevOps.
This would be very interesting for Secure features like ~"Category::License Compliance", ~"dependency scanning" and ~sast which are generally not dependent on previous jobs being finished. Adding internal customer customer because of that
Why not abandon the "stage" concept all together? if we have a DAG we can just draw that DAG with the minimal number of required "stages" in pipeline view..
Just add a mode, where jobs only "need" and "depend" on jobs the explicitly list.. "dependencies" imply "need" obviously.
Stage concept could be replaced by something like "type" so you could color different jobs to belong to a specific task, like "test", "build" whatever, so it looks nicer in the pipeline view.
@TimoWitte with https://gitlab.com/gitlab-org/gitlab-ce/issues/65505 you should be able to achieve having your entire DAG in a single stage. The reason we don't get rid of stages entirely is for compatibility with staged pipelines, or hybrid staged/DAG.
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.
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?
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?