0.9.1

Upgrading from an earlier version?

If you are upgrading an existing deployment, review the upgrade notes first.

New features (2)

1. User-chosen signup workspace names
   RepoFlow can now let users choose the name of the workspace provided to them when they register. The onboarding step supports built-in signup, OIDC/SSO, and LDAP. Automatic workspace creation remains optional and disabled by default. See Auto-Created Workspaces for configuration options and workspace limits.

2. Audit log export
   System and workspace audit logs can now be exported to CSV, either from the currently visible logs or for a selected date range.

Improvements (4)

1. Higher Nginx connection capacity
   Self-hosted deployment configurations now set worker_connections to 32768, preventing the Nginx image defaults from limiting active proxied requests to approximately 512 per worker.

2. Maven placeholder version support
   Maven POMs that use a property expression such as ${revision}, ${sha1}, or ${changelist} for the project version can now be uploaded through the RepoFlow UI and API by providing the resolved package version. Repository migrations derive the resolved version from the source repository path when the POM contains a placeholder. Concrete POM versions remain authoritative, and native mvn deploy behavior is unchanged.

3. Clearer package and version details
   Package pages now separate package-wide information from details for the selected version. A tooltip also clarifies that the package's last download is the most recent download across all its versions.

4. Redesigned account emails
   Redesigned the password-reset and account-verification emails.

Bug fixes (1)

1. Workspace audit log permissions
   Fixed workspace audit logs showing events that contain restricted information.

Upgrade notes

Existing workspace audit history

Audit logs created before this version will no longer be visible to workspace administrators after upgrading. They remain available to system administrators, and no audit logs are deleted.

Scale down before migrating

Multi-replica deployments must scale both the RepoFlow server and Hasura to one replica before starting the upgrade. Keep them at one replica until the upgraded server finishes its database migrations and starts successfully, then restore the normal replica counts. Ensure HASURA_UPGRADE_ON_START=true for the upgrade.

Deployment-specific steps

• Helm: No manual action is required. Upgrading the chart applies the new default. Set nginx.workerConnections to override it.
• All-in-one: No manual configuration is required. Recreate the container with the 0.9.1 image to apply the new limit.
• Docker Compose: Add the new nginx/nginx.conf file and mount it at /etc/nginx/nginx.conf. Follow Create the Nginx Configuration, then recreate the Nginx container.

Repair Docker image references

In some cases, RepoFlow versions before 0.9.0 created Docker images without all the required internal blob-reference records. Deleting another image that shares the same blobs in the repository could then delete blobs still required by the affected image.

We apologize for the disruption this issue may cause.

RepoFlow can detect these references and repair them when a valid blob still exists in the same repository. It cannot restore blobs that have already been deleted.

Step 1: Prepare RepoFlow

• For the safest and simplest procedure, scale the RepoFlow server to one replica and keep it at one replica until the migration finishes.
• Temporarily disable the server's liveness probe. A long migration can exceed the probe deadline because the server is not ready yet, causing the platform to restart it before the migration finishes.
• Keep the readiness probe enabled.

The migration runs before server startup completes, so a single-replica deployment will remain unavailable until it finishes. These requirements apply to both dry-run and repair mode.

Optionally, run two RepoFlow server replicas to keep RepoFlow available during the migration. To avoid edge cases caused by concurrent changes, we recommend pausing Docker pushes and deletions until the migration finishes. Docker pulls can continue normally.

Step 2: Run a dry run

Set the following environment variable and restart the RepoFlow server:

APPLICATION_MIGRATIONS_FORCE_RUN=docker-manifest-reference-backfill@0.9.1?mode=dry-run

The scan may take a long time on large repositories. As a rough reference, scanning approximately 3,000 tags took about 30 minutes in one deployment. Actual duration depends on the number of referenced manifests and blobs, database performance, and storage latency. The server logs progress and an estimated remaining time every 100 image tags.

Review the migration warnings and summary in the server logs. Dry-run mode reports detected issues without changing any reference records.

If blobs are already missing

If the dry run reports physical-object-missing, RepoFlow cannot restore that blob automatically. Re-push each affected tag from a trusted source, such as its original build pipeline, local image archive, or upstream registry. For a multi-platform image, re-push the complete tag with all its platforms. Then rerun the dry run and verify that the affected image can be pulled successfully.

If no trusted copy is available, restore the missing data from a backup or contact RepoFlow support before running repair mode. You do not need to re-upload unaffected tags.

Step 3: Back up and run the repair

If the dry-run results show repairable references, back up both the database and storage. Repair mode is irreversible.

Change the environment variable to repair mode and restart the server:

APPLICATION_MIGRATIONS_FORCE_RUN=docker-manifest-reference-backfill@0.9.1?mode=repair

After the migration finishes:

1. Review the migration summary in the server logs.
2. Remove APPLICATION_MIGRATIONS_FORCE_RUN.
3. Restore the liveness probe and normal replica count.
4. Restart the RepoFlow server normally.

Existing automatically created workspaces

Only relevant when IS_AUTO_CREATE_WORKSPACE_ON_SIGNUP was set to true before upgrading (disabled by default)

When enabled, RepoFlow provides each registered user with a workspace. This release also allows users to choose that workspace's name when AUTO_CREATED_WORKSPACE_NAME_MODE=user-provided.

Supporting user-chosen names changes how RepoFlow tracks signup workspaces: the user's account is now linked to the workspace provided during signup. Workspaces created by this feature before version 0.9.1 do not have that link.

If you previously enabled automatic signup workspaces, set the following environment variable and restart the RepoFlow server. RepoFlow will automatically find qualifying existing workspaces and create the required account-to-workspace links:

APPLICATION_MIGRATIONS_FORCE_RUN=signup-workspace-entitlement-backfill@0.9.1

The migration runs before server startup completes, so RepoFlow will remain unavailable until it finishes.

The migration links a workspace only when the user is already its administrator and its comment is exactly Automatically created by the system for user <email>. It does not change workspace permissions or memberships.

Before running it, review any workspaces where that comment was added manually. Change the comment if the workspace was not created by the signup feature, or the migration may link it as a signup workspace. Workspaces whose original automatic comment was edited or removed cannot be matched.

Remove APPLICATION_MIGRATIONS_FORCE_RUN after the migration finishes.