[GH-ISSUE #713] CI Integrations: publish a versioned GitLab CI/CD component template for asc #195

New issue

kerem · 2026-02-26T21:33:57+03:00

kerem commented

2026-02-26 21:33:57 +03:00

Originally created by @rudrankriyam on GitHub (Feb 21, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/713

Problem

GitLab users need a reusable, versioned way to install and run asc without duplicating pipeline shell snippets.

A modern GitLab integration should be component-based (catalog-friendly), parameterized, and safely consumable across GitLab.com and self-managed instances.

Goal

Publish a GitLab CI/CD component project for asc (plus practical template examples) with semver releases and catalog-ready structure.

Research (reference implementations and guidance)

GitLab component docs and migration guidance

CI/CD components overview, structure, include syntax, versioning.
- https://docs.gitlab.com/ee/ci/components/
Component best practices and migration examples.
- https://docs.gitlab.com/ee/ci/components/examples.html
- https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component

Strong reference component

GitLab AWS component pattern (spec:inputs, minimal focused job, branch/tag rules).
- https://gitlab.com/components/aws/-/raw/main/templates/ec2-deploy-production.yml

Proposal (v1 scope)

Create a dedicated project (suggestion: rudrankriyam/asc-ci-components) with catalog-compatible layout.

Repository structure

templates/
  install.yml
  run.yml
  auth.yml (optional if needed in v1)
README.md
LICENSE.md
.gitlab-ci.yml

Components (v1)

install
- Installs asc (versioned)
run
- Runs a provided asc command
- Depends on install behavior or inlines install logic

Inputs (minimum)

stage (default deploy)
job-prefix or job-name (to avoid name collisions)
asc_version (default latest)
command (required for run)
working_dir (default $CI_PROJECT_DIR)
profile (optional)

Optional auth-related inputs:

key_id
issuer_id
private_key_path
bypass_keychain

Design constraints from best practices

Avoid global keywords (default, global image) in component templates.
Replace hardcoded values with spec:inputs.
Use unique job naming strategy (job-prefix/job-name) to prevent merge conflicts.
Use $CI_SERVER_FQDN and $CI_API_V4_URL for portability.
Pin dependencies where practical; avoid moving targets in downstream dependencies.

Test and release requirements

Add project .gitlab-ci.yml that tests component usage by including components with @$CI_COMMIT_SHA.
Include validation jobs ensuring component jobs are present and executable.
Publish semantic version tags and release notes.
Make components CI/CD Catalog-ready.

Deliverables

Working component project with templates/*.yml and docs
Example consumer snippets for:
- single-job install+run
- staged pipeline usage
- self-managed compatible include form
Release process for component versions

Acceptance criteria

install and run components execute successfully in test pipelines.
Components can be included via version reference and commit SHA.
Inputs fully parameterize stage/job naming/version/command.
Docs include at least 2 practical include examples.
Initial semver release published and ready for catalog consumption.

Nice-to-have follow-ups

Add a higher-level testflight-release component wrapping common release flows.
Add artifact/report options (JSON output artifact capture) for downstream jobs.

Originally created by @rudrankriyam on GitHub (Feb 21, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/713 ## Problem GitLab users need a reusable, versioned way to install and run `asc` without duplicating pipeline shell snippets. A modern GitLab integration should be component-based (catalog-friendly), parameterized, and safely consumable across GitLab.com and self-managed instances. ## Goal Publish a **GitLab CI/CD component project** for `asc` (plus practical template examples) with semver releases and catalog-ready structure. ## Research (reference implementations and guidance) ### GitLab component docs and migration guidance - CI/CD components overview, structure, include syntax, versioning. - https://docs.gitlab.com/ee/ci/components/ - Component best practices and migration examples. - https://docs.gitlab.com/ee/ci/components/examples.html - https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component ### Strong reference component - GitLab AWS component pattern (`spec:inputs`, minimal focused job, branch/tag rules). - https://gitlab.com/components/aws/-/raw/main/templates/ec2-deploy-production.yml ## Proposal (v1 scope) Create a dedicated project (suggestion: `rudrankriyam/asc-ci-components`) with catalog-compatible layout. ### Repository structure ```text templates/ install.yml run.yml auth.yml (optional if needed in v1) README.md LICENSE.md .gitlab-ci.yml ``` ### Components (v1) 1. `install` - Installs `asc` (versioned) 2. `run` - Runs a provided `asc` command - Depends on `install` behavior or inlines install logic ### Inputs (minimum) - `stage` (default `deploy`) - `job-prefix` or `job-name` (to avoid name collisions) - `asc_version` (default `latest`) - `command` (required for run) - `working_dir` (default `$CI_PROJECT_DIR`) - `profile` (optional) Optional auth-related inputs: - `key_id` - `issuer_id` - `private_key_path` - `bypass_keychain` ## Design constraints from best practices - Avoid global keywords (`default`, global `image`) in component templates. - Replace hardcoded values with `spec:inputs`. - Use unique job naming strategy (`job-prefix`/`job-name`) to prevent merge conflicts. - Use `$CI_SERVER_FQDN` and `$CI_API_V4_URL` for portability. - Pin dependencies where practical; avoid moving targets in downstream dependencies. ## Test and release requirements - Add project `.gitlab-ci.yml` that tests component usage by including components with `@$CI_COMMIT_SHA`. - Include validation jobs ensuring component jobs are present and executable. - Publish semantic version tags and release notes. - Make components CI/CD Catalog-ready. ## Deliverables - Working component project with `templates/*.yml` and docs - Example consumer snippets for: - single-job install+run - staged pipeline usage - self-managed compatible include form - Release process for component versions ## Acceptance criteria - `install` and `run` components execute successfully in test pipelines. - Components can be included via version reference and commit SHA. - Inputs fully parameterize stage/job naming/version/command. - Docs include at least 2 practical include examples. - Initial semver release published and ready for catalog consumption. ## Nice-to-have follow-ups - Add a higher-level `testflight-release` component wrapping common release flows. - Add artifact/report options (JSON output artifact capture) for downstream jobs.

kerem

2026-02-26 21:33:57 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 21:33:58 +03:00

@rudrankriyam commented on GitHub (Feb 22, 2026):

Completed.\n\nDelivered in:\n- https://github.com/rudrankriyam/asc-ci-components/pull/1 (new official GitLab CI/CD component repo with install/run templates, docs, and self-test pipeline)\n- https://github.com/rudrankriyam/App-Store-Connect-CLI/pull/724 (README integration pointer/examples)

@rudrankriyam commented on GitHub (Feb 22, 2026): Completed.\n\nDelivered in:\n- https://github.com/rudrankriyam/asc-ci-components/pull/1 (new official GitLab CI/CD component repo with install/run templates, docs, and self-test pipeline)\n- https://github.com/rudrankriyam/App-Store-Connect-CLI/pull/724 (README integration pointer/examples)

Sign in to join this conversation.