Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 49,996
    • Issues 49,996
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,562
    • Merge requests 1,562
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #320778
Closed
Open
Issue created Feb 08, 2021 by Christian Steinmeyer@christian-steinmeyer

CI lint API doesn't properly lint local includes due to missing branch context

Release notes

Feature branches are a proven tool for clean development. The increasing functionality surrounding gitlab CI and its lint API make it easier to develop pipelines separated into multiple files. The existing API endpoints allow for linting of CI scripts that only include scripts on the default branch, but not newly added ones. By adding either a keyword or another variable to the project specific lint API, this can be solved.

Problem to solve

As a developer, I want to test new CI scripts with the linting API, so I can get faster feedback whilst using feature branches.

Intended users

  • Sasha (Software Developer)
  • Devon (DevOps Engineer)

User experience goal

The user should be able to test new CI scripts including referencing new files on a non-default branch with the project specific lint endpoint.

Proposal

Extend the existing API endpoint /api/v4/projects/:id:/ci/lint with either a flag like same_branch (telling it to consider the branch the call was triggered from), or another variable as in /api/v4/projects/:id:/ci/lint/branch/:id: so that it can be specified (e.g. using one of the available environment variables in CI.

Further details

  1. Create a new project to organize multiple ci-scripts
  2. Define a script that sends local files to the specified API endpoint (e.g. like this) and add it to the .gitlab-ci.yml
  3. Create a new branch for a new feature
  4. Add a new .yml file, e.g. including the definition of a single job
  5. Add a new .yml file, e.g. including the definition of a pipeline, referencing the local file from the previous step

Currently, this yields an error (Local file referenced.yml does not exist!), because only the default branch is considered (I assume). All logic necessary for the above seems already to be implemented, the only thing missing is the correct context of the feature branch.

Permissions and Security

Pretty much exactly like the existing ones, I suppose.

Documentation

Extend the existing docs.

Availability & Testing

Not sure.

Available Tier

Free, as the related features are free, as well.

What does success look like, and how can we measure that?

When performing the above steps and not receiving an error message.

What is the type of buyer?

Not sure.

Is this a cross-stage feature?

Not sure.

Links / references

Related to #217018 (closed) and #231352 (closed)

Edited Feb 08, 2021 by Christian Steinmeyer
Assignee
Assign to
Time tracking