Skip to content

Publish Releases without giving access to source code

Release notes

Previously, releases for public projects also allow access to the source code. With this update, you can now publish releases without giving access to the source code to users. This is useful for organizations that use releases as a way to give access to new versions of software but do not want the source code to be public.

Problem to solve

It's not uncommon for projects to be closed source (no public access to the source code) but publish some kind of compiled asset to the public (e.g. an .exe or a .dmg).

At the moment, GitLab does not support this use case. Current options are:

  1. Private projects, which requires that users who need to access the release assets be explicitly granted Guest permissions (which has its own issues: #213016 (closed))

  2. Public projects, which gives everyone full access to the source code

  3. Public projects with the Repository visibility set to "Only Project Members":

    image

    ... which also makes the Releases tab/page visible only to project members.

Intended users

Mostly Rachel (Release Manager).

Proposal

One option might be to add a new permission option under Settings > General > Visibility, project features, permissions to control the visibility of Releases:

image

Further details

One sticky detail that should probably be solved before this feature is delivered is how to reference and display Releases without exposing any tag data to users who shouldn't have access to repository information.

This issue is described in detail here: #213016 (closed)

Availability & Testing

Permissions and Security

As mentioned above, it's important for projects that do not make the source code available to the public that we don't publish any tag or commit info through the Releases page.

Documentation

Yes, this feature will require updates to our documentation.

What is the type of buyer?

Up for discussion. Most of our Release functionality is Core at the moment, but perhaps this functionality is specialized enough to warrant being restricted to a higher tier.

Links / references

Some related discussions:

Implementation plan

  • Remove the Releases feature toggle from the behind the split_operations_visibility_permissions FF - !99045 (merged)
Example diff 
diff --git a/app/assets/javascripts/pages/projects/shared/permissions/components/settings_panel.vue b/app/assets/javascripts/pages/projects/shared/permissions/components/settings_panel.vue
index a82f485bf44..91d645c524e 100644
--- a/app/assets/javascripts/pages/projects/shared/permissions/components/settings_panel.vue
+++ b/app/assets/javascripts/pages/projects/shared/permissions/components/settings_panel.vue
@@ -979,20 +979,20 @@ export default {
             name="project[project_feature_attributes][feature_flags_access_level]"
           />
         </project-setting-row>
-        <project-setting-row
+      </template>
+      <project-setting-row
           ref="releases-settings"
           :label="$options.i18n.releasesLabel"
           :help-text="$options.i18n.releasesHelpText"
           :help-path="releasesHelpPath"
-        >
-          <project-feature-setting
+      >
+        <project-feature-setting
             v-model="releasesAccessLevel"
             :label="$options.i18n.releasesLabel"
             :options="featureAccessLevelOptions"
             name="project[project_feature_attributes][releases_access_level]"
-          />
-        </project-setting-row>
-      </template>
+        />
+      </project-setting-row>
     </div>
     <project-setting-row v-if="canDisableEmails" ref="email-settings" class="mb-3">
       <label class="js-emails-disabled">
diff --git a/app/controllers/projects_controller.rb b/app/controllers/projects_controller.rb
index 5ceedbc1e01..145f27b4a21 100644
--- a/app/controllers/projects_controller.rb
+++ b/app/controllers/projects_controller.rb
@@ -435,13 +435,14 @@ def project_feature_attributes
       analytics_access_level
       security_and_compliance_access_level
       container_registry_access_level
+      releases_access_level
     ] + operations_feature_attributes
   end
 
   def operations_feature_attributes
     if Feature.enabled?(:split_operations_visibility_permissions, project)
       %i[
-        environments_access_level feature_flags_access_level releases_access_level
+        environments_access_level feature_flags_access_level
         monitor_access_level
       ]
     else
diff --git a/app/policies/project_policy.rb b/app/policies/project_policy.rb
index fb162d03955..83a9e3583a8 100644
--- a/app/policies/project_policy.rb
+++ b/app/policies/project_policy.rb
@@ -399,7 +399,7 @@ class ProjectPolicy < BasePolicy
     prevent(:admin_feature_flags_client)
   end
 
-  rule { split_operations_visibility_permissions & releases_disabled }.policy do
+  rule { releases_disabled }.policy do
     prevent(*create_read_update_admin_destroy(:release))
   end
  • Update ProjectPolicy to decouple release permissions from repository permissions. - !100170 (merged)
Example diff 
diff --git a/app/policies/project_policy.rb b/app/policies/project_policy.rb
index 9d121715d2c..2173b919a43 100644
--- a/app/policies/project_policy.rb
+++ b/app/policies/project_policy.rb
@@ -593,7 +593,6 @@ class ProjectPolicy < BasePolicy
     prevent :read_commit_status
     prevent :read_pipeline
     prevent :read_pipeline_schedule
-    prevent(*create_read_update_admin_destroy(:release))
     prevent(*create_read_update_admin_destroy(:feature_flag))
     prevent(:admin_feature_flags_user_lists)
   end

This 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.

Edited by Alishan Ladhani