The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Verify |
| Maturity | Minimal |
| Content Last Reviewed | 2023-12-15 |
Thanks for visiting this category direction page on Build Artifacts in GitLab. This page belongs to the Pipeline Security group of the Verify stage and is maintained by Jocelyn Eillis (E-Mail).
This category covers the experiences related to the display of artifact data. For more information, check out the features page.
For specific information and features related to display of artifact data, check out the GitLab Features and for information about administration of artifacts please reference the Job Artifact documentation. You may also be looking for one of the related direction pages from the Verify Stage.
This direction page is a work in progress, and everyone can contribute:
Artifacts are files created as part of a build process that often contain metadata about that build's jobs like test results, security scans, etc. These can be used for reports that are displayed directly in GitLab or can be published to GitLab Pages or in some other way for users to review. These artifacts can provide a wealth of knowledge to development teams and the users they support.
Job Artifacts and Pipeline Artifacts are both included in the scope of Build Artifacts to empower GitLab CI users to more effectively manage testing capabilities across their software lifecycle in both the gitlab-ci.yml or as the latest output of a job.
For information about storing containers or packages or information about release evidence see the Package Stage direction page.
Pipeline Security has released MVC UI functionality allowing the bulk delete of build artifacts through the Artifacts page.
There are no additional planned features for Build Artifacts in FY24 (2023-02 to 2024-01); however, Pipeline Security will continue to support high priority bug fixes for this category. Our team will also support community contributions to help advance this category at this time.
As we look forward to FY25, we will review our existing Build Artifacts capabilities against our long-term category vision. This assessment will help us understand the required investment and drive our next step(s) to advance the maturity of this category.
Our team's 3 month focus is to:
Our team plans to work on the following for 16.8:
@final job artifacts for GCP, AWS, and Azure. In 16.1, a bug was introduced when enabling job artifacts to be copied directly to their final location; this set of rake tasks will clean up orphaned objects created during this time period.Over the last 3 milestones our team has delivered the following:
artifacts:public keyword. Previously this was limited to only self-managed customers behind a feature flag. This setting enables users to control access of job artifacts of public pipelines.Although we do not plan on adding new features in FY24, we welcome and will support community contributions that align with our category vision. We are in the process of identifying potential issue candidates and providing information to ensure contributor success. If you have an issue you feel passionate about and want to contribute, please tag @jocelynjane with your interest.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
To meet our long term vision that enables users to more easily use and manage their Build Artifacts we will need to improve the usability of artifacts in the UI. In addition to UI improvements, we need to provide more APIs, broading our user-friendly solutions for build artifacts management. One example is the ability to use an API to upload artifacts directly to GitLab without them being generated by a pipeline.
The Gitlab Sales teams are looking for more complex ways for customers to make use of Ultimate and Premium features like SAST and DAST with monorepos by letting customers namespace parts of reports to more granular analysis or combining Matrix Builds and Metrics Reports.
The most popular customer request is for the ability to support the generation of multiple artifacts per job to reduce the need for pipeline logic to make select files available to later jobs.
Another popular customer request is the ability to reference child pipelines from the parent pipeline. Visibility/Traceability and seamless artifact handling for parent/child pipelines is a recurring usability theme we have heard from our customers.
One of our most complicated request, is to handle the expire_at experience in self-managed customers better. Today, our implementation deletes data for both GitLab.com and self-managed users - rather than allowing more control for our self-managed customers.
Although we have made improvements to expiration of artifacts, we continue to see customer struggles with reliability for removal of these expired artfacts and ensuring cleanup methods are removing all items.
The Gitlab quality team has requested the ability to upload artifacts from a job when it fails due to a timeout to assist in debugging those pipeline failures.
The team is also investigating performance issues related to the build artifact feature set as part of our focus on Availability and Performance.