GHARuns: A Large Dataset of GitHub Actions Workflow Execution Metadata

This dataset is the data artifact for the paper:GHARuns: A Large Dataset of GitHub Actions Workflow Execution Metadata. It contains GitHub Actions workflow execution metadata collected to support large-scale empirical studies of workflow runtime behaviour, including workflow runs, jobs, and steps. Extraction tool:The source code for the tool used to collect and curate this dataset is available at:https://github.com/sgl-umons/gharuns-collector Dataset organization:The dataset is distributed in two complementary layers. 1. Processed analytical tables in Parquet format.These files provide the finalized post-processed representation used for analysis. 2. Raw metadata in compressed JSONL format.These files preserve richer metadata from the GitHub API for the same aligned subset of entities. Files included:- runs.parquet- jobs.parquet- steps.parquet- runs.jsonl.zst- details.jsonl.zst Relationship between Parquet and JSONL files:The three Parquet files represent the final cleaned analytical layer of the dataset. - runs.parquet contains one row per workflow run.- jobs.parquet contains one row per job.- steps.parquet contains one row per step. The two JSONL files provide the raw API metadata layer, filtered so that they correspond to the same finalized entities represented in the Parquet files. - runs.jsonl.zst contains raw run-level JSON objects for the run IDs present in runs.parquet.- details.jsonl.zst contains raw job-level and nested step-level JSON objects for the job IDs present in jobs.parquet. This means that the JSONL files preserve richer metadata than the Parquet files while remaining aligned with the finalized analytical subset used in the processed dataset. File overview: File name Format Level of observation Purpose runs.parquet Parquet Workflow run Run-level metadata used for analysis jobs.parquet Parquet Job Job-level metadata used for analysis steps.parquet Parquet Step Step-level metadata used for analysis runs.jsonl.zst JSONL (zst compressed) Workflow run Raw run payloads with full metadata for the aligned run subset details.jsonl.zst JSONL (zst compressed) Check suite / jobs / nested steps Raw detailed payloads containing jobs and their nested steps for the aligned job subset Parquet schemas: File: runs.parquetEach row corresponds to one workflow run.Fields:- id: workflow run ID- check_suite_id: associated check suite ID- repository: repository full name- path: workflow file path- name: workflow run name- event: triggering event- run_attempt: attempt number of the run- head_sha: commit SHA associated with the run- head_branch: branch associated with the run- status: run status- conclusion: run conclusion- run_started_at: run start timestamp- updated_at: last update timestamp- original_repo_name: original repository name used for provenance tracking File: jobs.parquetEach row corresponds to one job belonging to a workflow run.Fields:- id: job ID- check_suite_id: associated check suite ID- name: job name- status: job status- conclusion: job conclusion- started_at: job start timestamp- completed_at: job completion timestamp File: steps.parquetEach row corresponds to one step belonging to a job.Fields:- job_id: parent job ID- step_number: step order within the job- name: step name- status: step status- conclusion: step conclusion- started_at: step start timestamp- completed_at: step completion timestamp Raw JSONL structure: File: runs.jsonl.zstThis file contains one JSON object per workflow run. It preserves the raw run metadata returned by the GitHub API for the aligned run subset. Representative fields include:-Run identifiers: id, node_id, workflow_id, check_suite_id, check_suite_node_id- Workflow context: name, path, display_title, event, run_number, run_attempt- Execution state: status, conclusion, created_at, updated_at, run_started_at- Git context: head_branch, head_sha, head_commit- Repository context: repository, head_repository- User context: actor, triggering_actor- API and resource links: url, html_url, jobs_url, logs_url, workflow_url, artifacts_url, rerun_url, cancel_url These fields are useful for analyses requiring richer provenance or contextual metadata beyond the normalized Parquet layer. File: details.jsonl.zstThis file contains one JSON object per detailed check-suite-level record, including nested jobs and nested steps. Top-level fields:- databaseId- checkRuns Within checkRuns.nodes, each job record includes:- databaseId- name- status- conclusion- startedAt- completedAt- steps Within steps.nodes, each step record includes:- number- name- status- conclusion- startedAt- completedAt This file is useful for researchers who need access to the hierarchical raw structure of jobs and steps or who want to inspect metadata not retained in the flat Parquet tables. Why both Parquet and JSONL are provided:The dataset intentionally provides both representations because they support different research needs. Parquet files are intended for:- efficient loading into analytical tools such as pandas, Polars, DuckDB, Spark, or R- direct use in statistical analysis and modeling- compact, columnar access to the main cleaned metadata JSONL files are intended for:- access to full raw API metadata- recovery of fields not preserved in the processed tables- exploratory analyses involving nested or less commonly used attributes- reproducibility and transparency of the post-processing pipeline In short, the Parquet files are the final analytical representation, while the JSONL files are the aligned raw metadata representation. Examples of metadata available in JSONL but not fully represented in Parquet include:- actor and triggering actor information- repository and head-repository objects- pull request associations- referenced reusable workflows- detailed commit metadata- API URLs and HTML URLs- nested job and step objects in their original hierarchical structure Recommended use:- Use the Parquet files for scalable analysis and direct statistical processing.- Use the JSONL files when richer provenance, nested structure, or unnormalized metadata is required.- Use both layers together when reproducing the cleaning pipeline or extending the dataset with additional metadata extraction.