Skip to content

Add GitHub Actions e2e dispatch workflow (JFrog Pipelines EOL migration) - #3701

Open
agrasth wants to merge 2 commits into
masterfrom
add-e2e-dispatch-github-workflow
Open

Add GitHub Actions e2e dispatch workflow (JFrog Pipelines EOL migration)#3701
agrasth wants to merge 2 commits into
masterfrom
add-e2e-dispatch-github-workflow

Conversation

@agrasth

@agrasth agrasth commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Ports jfrog_artifactory_ecomatrix_cli_e2e from .jfrog-pipelines/pipelines.yml to a workflow_dispatch GitHub Actions workflow, as part of migrating off JFrog Pipelines (EOL).

This is a best-effort port, not a byte-for-byte translation — please review before merging.

The pipeline is really two things: (1) a GitHub Actions dispatch-and-poll harness that mints an OAuth token and triggers/monitors ~16 test workflows in jfrog-cli-workflows, and (2) two calls out to a Jenkins job (tools/platform/environment_setup_gen2 and tools/platform/environment_operate) to stand up and tear down an ephemeral Artifactory.

  • Part 1 is carried over near-verbatim. The original bash was already host-agnostic curl/jq against a configurable GITHUB_API_URL (defaults to https://github.jfrog.info/api/v3) — copied essentially unchanged into a run: step.
  • Part 2 is reimplemented, not ported, because JFrog Pipelines' native Jenkins step type doesn't expose how it talks to Jenkins in the YAML — there's nothing to literally copy. I implemented it against the generic Jenkins remote-build API: fetch a CSRF crumb, POST to buildWithParameters, follow the returned queue-item until it has a build, then poll that build until it completes. This needs verification against your actual Jenkins instance — in particular whether the job path tools/platform/environment_setup_gen2 resolves the same way via /job/tools/job/platform/job/environment_setup_gen2/ as it does through the native integration, and whether crumb-based CSRF is even enabled there.
  • Network reachability is unverified: this job needs outbound access to https://github.jfrog.info (JFrog's GHE instance) and to the Jenkins host from wherever it runs. If either is only reachable from inside JFrog's network, this workflow needs a self-hosted runner rather than ubuntu-latest — I don't have visibility into that from the YAML alone.

Secrets required (repo Settings → Secrets and variables → Actions):

  • JFROG_CLI_TESTS_MASTER_KEY, JFROG_CLI_TESTS_USERNAME, JFROG_CLI_TESTS_PASSWORD, JFROG_CLI_TESTS_TOKEN — from the jfrog_cli_tests integration
  • GITHUB_DISPATCH_TOKEN — from the github_dispatch integration (must be a fine-grained PAT or GitHub App token; the JFROG org on github.jfrog.info rejects classic PATs)
  • JFROG_CLI_GH_TOKEN — fallback token from jfrog_cli_gh, used only if GITHUB_DISPATCH_TOKEN is unset
  • JENKINS_ENTPLUS_RT_URL, JENKINS_ENTPLUS_RT_USER, JENKINS_ENTPLUS_RT_TOKEN — from the jenkins_entplus_rt integration

Not run yet — needs the secrets above added first, and the Jenkins-triggering steps verified against the real instance.

JFrog Pipelines is EOL. Ports jfrog_artifactory_ecomatrix_cli_e2e from
.jfrog-pipelines/pipelines.yml to a workflow_dispatch GH Action.

Best-effort port: the GitHub Actions dispatch-and-poll logic (the bulk of
the pipeline) is carried over near-verbatim since it was already
host-agnostic bash. The two Jenkins-triggered steps (provisioning and
tearing down the ephemeral Artifactory) are reimplemented against the
generic Jenkins remote build API (crumb + queue polling), since JFrog
Pipelines' native Jenkins step type doesn't expose how it itself talks to
Jenkins -- this needs verification against the real Jenkins instance.

Needs secrets: JFROG_CLI_TESTS_MASTER_KEY, JFROG_CLI_TESTS_USERNAME,
JFROG_CLI_TESTS_PASSWORD, JFROG_CLI_TESTS_TOKEN, GITHUB_DISPATCH_TOKEN,
JFROG_CLI_GH_TOKEN, JENKINS_ENTPLUS_RT_URL, JENKINS_ENTPLUS_RT_USER,
JENKINS_ENTPLUS_RT_TOKEN.
Moves the shell logic out of the workflow's run: blocks into
.github/scripts/e2e-dispatch.sh, restructured to use plain local variables
instead of GitHub Actions step outputs, so it can be exported-env-vars-and-run
directly from a local checkout, not just triggered via workflow_dispatch.

# --- Mint an OAuth token against the (now ready) environment ---
echo "Installing JFrog CLI 2.54.0"
curl -fL https://getcli.jfrog.io/v2 | sh -s 2.54.0

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not latest version?

# LOGS_TO_KIBANA=true DEPLOYMENT_SIZING=common
# MAX_RUN_RETRIES=2 MAX_WAIT_SECONDS=14400
#
# NOT independently verified against a real Jenkins instance: the provision/

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can create a test job verify to address any hidden scenarios

uses: actions/checkout@v4

- name: Run e2e dispatch
run: .github/scripts/e2e-dispatch.sh

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of using the script, cant we invoke using github actions itself and check their status or using gh cli.

if [[ "${SKIP_ENV_SETUP}" != "true" ]]; then
echo "Provisioning ephemeral Artifactory..."
job_path="job/tools/job/platform/job/environment_setup_gen2"
crumb_json=$(curl -sS -u "${JENKINS_USER}:${JENKINS_TOKEN}" "${JENKINS_URL}/crumbIssuer/api/json" || echo '{}')

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use an existing github action or write reusable github action to reuse it across the workflows instead of simple script which can trigger jenkins job that way you can maintain and scale triggering jenkins jobs

# Ported from .jfrog-pipelines/pipelines.yml (JFrog Pipelines is EOL).
#
# Runnable both from the "E2E Dispatch" GitHub Actions workflow and from a
# local shell. To run locally, export the env vars below (same names the

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To run locally
why do we need to run locally? Isnt it from CI 100% of the times?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants