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 | 2024-06-10 |
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.
We do not have plans to deliver new features for Build Artifacts in the upcoming year. 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.
In addition, 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. We will also evaluate adding capabilities to the Artifacts page we released in 2023 to advance artifact management usability.
Our team's 3 month focus is to:
Our team plans to work on the following for 17.0:
Over the last 3 milestones our team has delivered the following:
@final job artifacts for Azure has been completed.@final job artifacts for GCP, AWS in GitLab.com, which automatically cleaned up orphaned artifacts for our .com customers.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 this year, we welcome and support community contributions that align with our category vision. You can find our list of issues ready for contribution here. If you have an issue that is not on this list, but you feel passionate about it and want to contribute, please tag @jocelynjane with your and we will work with you to determine a path forward and connect you with our community contribution team to ensure your success.
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.
Additionally, the pipeline security of Build Artifacts is a critical piece to the overarching goal of ensuring security of the entire software supply chain. Examples of security measures include signing prevent tampering and validation of artifact authenticity; additional access restrictions for different types of artifacts; and controls to ensure compiance with regulartory requirements for artifact management/storage.
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.