FAQs

Yes, you can build and store your custom image in your GitLab Project container registry.

You can also contribute your custom image to the Pipeline COE (innersource). For more details, refer to Pipeline COE.

Yes, GitLab Pages feature is available on SHIP-HATS. This feature allows you to publish static websites directly from a repository in GitLab, making it easier to share your work with others. [Learn more]

Yes. Viewers of the GitLab wiki page must have access to your Confluence link to route from GitLab to Confluence.

Creating a project token allows users to access the Command Line Interface (CLI) but not the User Interface (UI). For UI access, users will still need to authenticate using TechPass, which is licence-based.

You will need to define needs:project in a job of your subsequent pipeline. In this case, you will need to have a different branch (i.e., main branch for the subsequent pipeline and branch-A for the previous pipeline). Refer to GitLab documentation.

We are working on compliance version release management. You will be able to upgrade at your own convenience by changing the version to reference. Compliance Framework

Yes. From GitLab 18.11 onwards, GitLab supports self-service creation of service accounts. For details, including any applicable prerequisites, see GitLab service accounts.

Your role was changed to Guest because you do not have a valid GitLab licence provisioned through SHIP-HATS. Users without a GitLab licence can only be assigned the Guest role. If a higher role is assigned to them, SHIP-HATS automatically changes their role back to Guest.

If you need the Developer, Maintainer, or Owner role, ask your SHIP-HATS Subscription Admin (SA) to provision a GitLab licence for you. If you are a GovTech Public officer, go to the Equip portal to check whether you are eligible for a GitLab licence. If you are eligible, you can request one there.

Note: SHIP-HATS may block your account if a role higher than Guest is repeatedly assigned to you without a valid GitLab licence. If your account is blocked, you cannot sign in to GitLab, even if you have an active TechPass. To unblock your account, contact us.

Your GitLab account may be deactivated for one of the following reasons:

Inactive account: Your account has been inactive for an extended period, in accordance with the GitLab policy. Expired invitation: You did not accept your GitLab invitation within 7 days.

Note: This is different from an account being blocked because of repeated attempts to assign a role higher than Guest to a user without a valid GitLab licence.

If you need your account reactivated, contact your SHIP-HATS Subscription Administrator (SA).

To reactivate your GitLab account, log in to GitLab with your TechPass ID.

To enhance security and manage risk, SHIP-HATS is reducing the default expiry period for GitLab tokens from 365 days to 180 days, effective 15 October 2024. Depending on when your token was created, here’s what you need to know:

Use case 1: Token expiring after 15 October 2024

• Scenario: A user created a GitLab token on 05 November 2023, with a 365-day expiry.
• Analysis: The token’s expiry date is 04 November 2024. As of 15 October 2024, there are 21 days remaining until the token expires. This is within the new 180-day limit.
• Action: No immediate action is required. When the token expires on 04 November 2025, the user should generate a new token with a maximum 180-day expiry.

Use case 2: Token expiring after the new 180-day limit

• Scenario: A user created a GitLab token on 05 August 2024, with a 365-day expiry.
• Analysis: The token’s expiry date is 04 August 2025. As of 15 October 2024, there are 294 days remaining until the token expires. As this exceeds the new 180-day limit, the token becomes invalid.
• Action: The user must generate a new token with a maximum 180-day expiry before 15 October 2024, to avoid token invalidation.

Use case 3: Token expiring exactly at the 180-Day limit

• Scenario: A user created a GitLab token on 13 April 2024, with a 365-day expiry.
• Analysis: The token’s expiry date is 12 April 2025. As of 15 October 2024, there are exactly 180 days remaining until the token expires. This aligns with the new limit.
• Action: No immediate action is required. When the token expires on 12 April 2025, the user should generate a new token with a maximum 180-day expiry.

Consider using ship-hats-templates to overcome these errors. Refer to Common Functions in GitLab.

Cloudflare offers a root certificate, which could potentially address the issue. You may try installing the Cloudflare root certificate to your system and Git application.

Make sure that Need artefact:path is defined.

Baseline configuration limits each repo size to 2GB. GitLab repositories are code repositories. Therefore, it is recommended that they do not store binaries like executables, pictures, or videos, etc.

If your GitLab repo size exceeds 2GB, consider reducing size. For further support, raise a service request with your requirement.

As GitLab is hosted on AWS, the traffic between GitLab and S3 will be transmitted over the AWS global network backbone. For more details, refer to AWS questions.

Yes, the groups have reporter roles, limiting their access to viewing data only. The collected data is used solely for improving GitLab services and is handled securely.

Yes, you can remove individual users who do not belong to the specified WOG groups. By addressing these common questions, the FAQs provide clear and concise information to users about the inherited WOG groups.

Owner or Maintainer (i.e., Project Admin) can assign the roles for GitLab project members. For more details, refer to GitLab documentation.

Note that when GitLab licences are provisioned to users via Console, the PA must invite the required users to GitLab groups or projects within 7 days.

Refer to GitLab roles and permissions documentation. You can configure Project Settings in GitLab for additional changes, such as restricting certain groups/users to merge a merge request or push commit on a protected branch and merge request approval.

Yes, SHIP-HATS GitLab has a disaster recovery plan in place. For more details, refer to GitLab Dedicated SLAs: Disaster Recovery Plan.

Currently, having a second region for disaster recovery is pending.

Yes, there is a soft deletion period of 7 days for groups and projects.

There are 2 types of runners available for our subscribers:

• Shared runners: These are hosted and maintained by SHIP-HATS team.
• Agency-hosted runners: These are dedicated runners set up and maintained by the agencies in their environment.

For more details, refer to Shared runners vs Agency-hosted runners.

Yes, agencies can host and manage their runners. These are Agency-hosted runners. Note that agencies need to have the required technical expertise to configure and manage their runners and they need to bear the cost of their runners.

Refer to [Comparison of shared runners](https://docs.developer.tech.gov.sg/docs/ship-hats-docs/tools/gitlab/runners?id=comparison-of-shared-runners.

Agencies may Set up their own GitLab runners, if they require different settings.

We do not have macOS runner support at the moment. For now, we suggest that you try hosting your own macOS runners.

Yes. Refer to Shared runners.

Yes, agencies can host and manage their own GitLab runners in their environment. For more details, refer to Agency-hosted runners.

Several factors can affect the performance of GitLab Runner. Here are some steps users can take to troubleshoot and potentially resolve the issue before logging a support request (SR):

# Issue: Image unavailable

Resolution

1. Check the image/configurations and ensure there are no typos in the image reference.
2. Pull the image from your local machine to confirm that the image reference is correct.

# Issue: Image too big

Resolution

Reduce the size of the image.

# Issue: Remote container registry down / rejects pulls due to limits reached (Eg, MCR / Dockerhub)

Workaround

1. Make a copy of the image in your project’s container registry.
2. Update the image reference in your configuration to use this local copy.

# Issue: Connectivity/Registration issues

Resolution

1. Check if the runner is agency-hosted.
2. If yes, switch the job’s runner tag to cstack, ship_docker, or ship_docker_windows.
3. Run the job again to check if the issue persists.

# Issue: GitLab Server Slowness

Resolution

• Report the issue to SHIP-HATS with relevant logs and description.

If you are using dedicated Agency-hosted runners, you can set your desired job log limit for the output_limit parameter in your config.toml file. For more details, refer to Configure GitLab Runner - Advanced configuration.

There is a project-level job timeout setting. The default timeout is 1 hour, and you can set it up to a maximum of 1 month. However, the overall job timeout cannot exceed the runner’s timeout, which is configured separately and has a maximum of 2 hours.

This error occurs because the necessary tools for the native scanner are installed under the root user in the image.

To resolve this issue:

• Use the ship_docker runner for your job.
• The ship_docker runner ensures that the scanner has the correct permissions and environment to run successfully.

For GCC, the users can use SHIP-HATS Shared Runner and for OnPrem, users need an Agency-hosted Remote Runner.

To resolve this issue, please use the ship_docker runner. The necessary tools are installed under the root user in the image, and using the ship_docker runner will ensure that the scanner runs correctly.

Refer to Known issues after migrating to GitLab-hosted runners.

Yes, GitLab-hosted shared runners can be used to build Maven projects. As these runners are Docker-based, they can run build jobs within a specified container image. Refer to example: https://gitlab.com/gitlab-examples/maven/simple-maven-example/ to understand how it is possible to specify a container image that includes Maven.

The Shared Runners will not be able to accommodate large size docker image. In this scenario, we recommend that you use own runners where you will have more control over the storage size of the runner itself.

Refer to steps to set up your own runners(agency-hosted runners) and Runners.

Refer to the COE template for Awscli Docker Image.

SHIP-HATS’s shared runners use internet traffic for AWS API.

Runners (Shared or Dedicated) are used for deployment in SHIP-HATS.

For intranet deployment, you need to use self host runner in intranet to do integration tests against your intranet service by providing the required network access.

Every SaaS has different integration capability. Therefore, it depends on the product.

You can use the Build and push docker image template. This template allows you to build and push docker image to private registry in one single action which is defined in the “script” key.

Note: This template might be updated in the future to use other docker alternatives.

In SHIP-HATS Templates (from tag v1.0.4), the docker alternative tools used in our templates include Kaniko, Skopeo, and Crane.

In our testing, Buildah and Podman require minimally some elevated capabilities on runner to work. These elevated capabilities are undesirable in a shared runner model as they allow host escape. So, SHIP-HATS Templates leverage several tools that do not require such runner settings to fulfil some docker commands. For example:

• Kaniko is able to build an image from a Dockerfile and push it to a registry. For example, it is ideal to replace docker build and docker push commands.
• Skopeo is known for copying an image from and to various storage mechanisms. For example, it is ideal to replace docker tag.
• Crane is a tool for interacting with remote images and registries. For example, it is ideal to replace docker pull and docker push (that cannot be performed by Kaniko and Skopeo).

No, there are certain functions that cannot be performed by the suggested docker alternatives, such as docker run and docker compose. You may consider using GitLab services with your services designed to provide additional features which are network accessible.

SHIP-HATS does not support Docker-in-Docker (dind) or privileged shared runners. You need to self-host privileged runner to use dind image for running docker commands directly. Refer to Set up agency-hosted GitLab runners.

Based on our testing on docker alternatives, Skopeo and Crane can run on non-root and non-privileged runners (tags: cstacks, non_privileged, no_root) whereas Kaniko can run on runners with root and non-privileged runners (tags: ship_docker, non_privileged).

Pipeline COE is an InnerSource project where custom images are built and shared across all projects. Most images in Pipeline COE are built from container base image that comes with multiple common tools (e.g., Wget, Git, curl, and JQ).

Please note that this project is a work in progress and the location of the images might be changed later. You may refer to the images there in your job should you find any one suitable.

If you are unable to find a suitable image in Pipeline COE, you may raise a request or if you find an image that can add on the tools that you require, you may edit the Dockerfile and raise an MR for platform team to review and approve.

There is no additional cost for using shared runners. There is charges for VPC connection endpoint (AWS cost) and the cost for hosting your own runners (i.e. EC2).