gigawork
An automated tool for extracting GitHub Actions' workflows from Git repositories written in Python.
gigawork (Give me GitHub Actions Workflows) is primarily designed to be used as a command-line tool.
Given a Git repository, it extracts the different workflows and their versions from the Git history.
The extraction is done by traversing the Git history of the repository and going back in time respecting the first-parent rule until the first commit (or the given reference) is reached.
The workflows are saved in a given directory along with relevant metadata (see Usage) in a given CSV file.
This project is developed by Guillaume Cardoen at the Software Engineering Lab of the University of Mons (Belgium).
@inproceedings{cardoen2024dataset,
title={A dataset of Github Actions workflow histories},
author={Cardoen, Guillaume and Mens, Tom and Decan, Alexandre},
booktitle={Proceedings of the 21st International Conference on Mining Software Repositories},
pages={677--681},
year={2024}
}
Installation
The easiest way to install gigawork is to install from Pypi
pip install gigawork
Another easy way to install gigawork is via pip from this GitHub repository
pip install git+https://github.com/sgl-umons/gigawork
Alternatively, you can clone this repository and install it locally
git clone https://github.com/sgl-umons/gigawork
cd gigawork
pip install .
You may wish to use this tool in a virtual environment. You can use the following commands.
virtualenv gigawork_venv
source gigawork_venv/bin/activate
pip install gigawork
Usage
After installation, the gigawork command-line tool should be available in your shell. Otherwise, please replace gigawork by python -m gigawork. The explanations in the following stays valid in both cases.
You can use gigawork with the following arguments:
Usage: gigawork [OPTIONS] REPOSITORY
Extract the GitHub Actions workflow files from a single Git repository
`REPOSITORY`. The extraction is done by traversing the Git history of the
repository starting from the reference given to `-r` and going back in time
respecting the first-parent rule until the first commit (or the reference
given to `-a`) is reached. The Git repository can be local or distant. In
the latter case, it will be pulled locally and deleted unless specified
otherwise. Every extracted workflow file will be stored in the directory
given to `-w` (or the directory `workflows` if not specified). The metadata
related to the extracted workflows will be written in the CSV file given to
`-o`, or in the standard output if not specified. The metadata related to
the renaming of workflows will be stored in the CSV file given to `-ro`, or
not stored if not specified.
Example of usage: gigawork myRepository -n myRepositoryName -s directory -o
output.csv --no-headers
Options:
-r, --ref, --branch REF The most recent commit reference (i.e.,
commit SHA or TAG) to be considered for the
extraction.
-s, --save-repository DIRECTORY
Save the repository to the given directory
in case `REPOSITORY` was distant.
-u, --update Fetch the repository at the given path.
-a, --after REF Only consider commits after the given commit
reference (i.e., commit SHA or TAG).
-w, --workflows DIRECTORY The directory where the extracted GitHub
Actions workflow files will be stored.
-o, --output FILE The output CSV file where information
related to the dataset will be stored. By
default, the information will written to the
standard output.
-sa, --save-auxiliaries If the information related to the auxiliary
files will be stored. By default, the
information will not be stored.
-n, --repository-name TEXT Add a column `repository` to the output file
where each value will be equal to the
provided parameter.
--no-headers Remove the header row from the CSV output
file.
-h, --help Show this message and exit.
The CSV file given to -o (or that will be written to the standard output by default) will contain the following columns:
repository: the name of the repository if-nwas specifiedcommit_hash: the commit SHA of the commit where the workflow file was extractedauthor_name: the name of the author of the commitauthor_email: the email of the author of the commitcommitter_name: the name of the committer of the commitcommitter_email: the email of the committer of the commitcommitted_date: the committed date of the commitauthored_date: the authored date of the commitfile_path: the path of the workflow file in the repositoryprevious_file_path: The path to this file before it has been touchedfile_hash: the SHA of the workflow file (and so, its name in the output directory)previous_file_hash: The name of the related workflow file in the dataset, before it has been touchedchange_type: the type of change (A for added, M for modified, D for deleted). Note that a renamed file will be seen as a modification.valid_yaml: a boolean indicating if the file is a valid YAML file.probably_workflow: a boolean representing if the file contains the YAML keyonandjobs. (Note that a file can be an invalid YAML file while having this value set to true).valid_workflow: a boolean indicating if the file respect the syntax of GitHub Actions workflow. A freely available JSON Schema was used in this goal. This schema is neither made nor maintained by the authors of this repository. It was originally found on https://json.schemastore.org/github-workflow.json
Examples
As an example, the following command extracts every workflow files from the repository example_repository, add the name my-example-name in the output. It also saves various information (such as commit SHA, author name, ...) in output.csv (with the headers as --no-headers is not specified). Each workflow file will be saved in the directory workflows (which is also the default save directory).
gigawork example_repository -n my-example-name -o output.csv -w workflows
Note that the repository does not have to be already cloned. The tool can fetch it for you and clean up (unless told otherwise) when the work is done. An example is shown below. The GitHub repository https://github.com/sgl-umons/gigawork will be fetched, saved under the gigawork directory and the repository column will be gigawork_name in the resulting CSV file. Note that, if -s gigawork was not specified, the tool will create a temporary directory and clean up when it finishes.
gigawork https://github.com/sgl-umons/gigawork -n gigawork_name -s gigawork -o output.csv
License
Distributed under GNU Lesser General Public License v3.
Metadata
Release files for gigawork 1.4.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| gigawork-1.4.3.tar.gz | 30.4 kB | With provenance | Details for gigawork-1.4.3.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| gigawork-1.4.3-py3-none-any.whl | Python 3 | none | any | Details for gigawork-1.4.3-py3-none-any.whl |
Total release size: 60.9 kB
Release files / gigawork-1.4.3.tar.gz
| Download URL | gigawork-1.4.3.tar.gz |
|---|---|
| Size | 30.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f419aab1060b0e72538456e1298d187abd6c38c71418ffc732b22e839a178a19
|
|
BLAKE2b-256 checksum How to use checksums |
2b25c20df4ec8826f2c732fd0a50debaf6d08d27e22db86d697ee9df49e720e8
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Dec 18, 2025.
Transparency logRelease files / gigawork-1.4.3-py3-none-any.whl
| Download URL | gigawork-1.4.3-py3-none-any.whl |
|---|---|
| Size | 30.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5566660cece8b69721414aea5dcb630823d75d16691b9438a9ade87df593ef4f
|
|
BLAKE2b-256 checksum How to use checksums |
8c0689bb4d07c1869eed4eab42e533fcd900f142a567cbdbd59a150d943605c0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.7
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Dec 18, 2025.
Transparency logSecurity for gigawork 1.4.3
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
Both files in this release have been uploaded with provenance metadata.
Attestation for gigawork-1.4.3.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Dec 18, 2025.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.