Skip to content

datalad/git-annex

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

425 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

datalad/git-annex

The purpose

Downstream testing

The primary goal for the repository is to provide extensive automated testing of fresh builds of git-annex using its built-in test battery across various base operating systems and environments, and against our downstream DataLad project.

Distribution

As a side-artifact of the build during the testing process, we provide non-official automated builds of git-annex. They are attached as artifacts to the CI runs, and, for the git-annex releases, also to the Releases page. All build logs and builds are archived "privately" on an internal server using con/tinuous, and release builds are then re-shared from the ///datalad/packages DataLad package.

These builds are non-official builds of git-annex and their functioning might differ from the official builds.

AI Disclaimer

Agentic AI tools might be used for various aspects of the troubleshooting, development, and maintenance in this repository. We strive to provide our best effort for adequate provenance and attribution on AI-assisted work in commit messages, patch headers, and issues.

Structure and workflow

Branches

This repository contains two primary branches:

  • upstream/master - an unmodified mirror of the master branch from the original git-annex repository, and
  • master - CI configuration, associated scripts, and potential patches on top of upstream/master, which are then applied at build time.

As a result, the builds provided here may function differently than the official original builds of git-annex. This repository also contains issues which might be specific to these builds and not necessarily relevant to the original git-annex.

Submitting Patches

Patches to the git-annex source code can be added by opening a pull request against master that adds a Git patch file with a .patch file extension to the patches/ directory; the CI will then build git-annex with this patch (and any others currently in patches/) applied. If the patch fails to apply or appears to have already been applied upstream, the builds will fail.

It is recommended that patches be given names of the form YYYYMMDD-{commit}-{brief_description}.patch, where {commit} is the short hash of the git-annex source code commit against which the patch was made.

Once a patch PR is merged into master, the patch will be applied to all git-annex builds on all platforms, including release builds. Patches in patches/ are applied in lexicographic filename order. If a patch in patches/ gets applied upstream, a PR will automatically be created to delete the file from patches/, and the patch will be skipped. If a patch fails to apply, an issue will be automatically created in this repository, and the build will fail.

Status

Update mirror

Build git-annex & test DataLad against it

Ubuntu macOS Windows

Client Tests

Client Test Status
openmind7 Overall test status git-annex-home test status git-annex-om2 test status
ndoli Overall test status git-annex-home test status git-annex-tmp test status
smaug Overall test status git-annex test status

Builds of whls for PyPI (by @psychoinformatics-de)

Linux MacOS (13, Intel) MacOS (14, M1) Windows

Test git-annex wheel from PyPi

About

A non-official testing bed and distribution of git-annex established for DataLad purposes. No PRs will be merged, but could be used to test perspective git-annex patches. Official git-annex repository: https://git.kitenet.net/index.cgi/git-annex.git/

Resources

Stars

Watchers

Forks

Packages

 
 
 

Contributors