Git Product home page Git Product logo

submodule-branch-check-action's Introduction

submodule-branch-check-action

A github action to ensure that a submodule is progressing to a child of the previous version (or not changing) and/or that the new submodule version is on a specific branch.

Inputs

path (required)

The path to the submodule, this is required. Do not include leading or trailing slashes. Note: this must be the path the submodule is located at in the repo!

branch (optional)

The name of a branch that the submodule hash must be on (after the push or on the head PR branch)

first_parent (optional)

Require the submodule's checked-out commit to be an ancestor of the specified branch strictly along the path following first parents only. That is, the submodule's current HEAD must either currently be or have at some point in the past been the tip of the branch specified.

pass_if_unchanged (optional)

For pull request only, if this is included the check will automatically pass if none of the commits modify the submodule.

fetch_depth (optional)

Fetch depth for the two relevant branches on a PR trigger. The action will checkout the two branches to this depth, if you know your branches are relatively short lived compared to the full history of your repo this can save you some processing time, network traffic, etc. by only checking out enough to cover your needs instead of the default full history.

sub_fetch_depth (optional)

Fetch depth for the submodule being checked. This will check out every branch to this depth. By default the full history will be checked out. I recommend leaving this at default unless your submodule is excessively large. Due to the nature of submodules there are many situations where, if the submodule is in a weird state, you will not get descriptive errors without a full fetch.

require_head (optional)

If the submodule is required to be on the head (most recent commit) of the specified branch. Keep in mind that it is possible that this will pass on a PR at the time it is run but no longer be on the most recent at the time of merge. Branch must also be specified for this to be checked.

disable_progression (optional)

Include this parameter to skip the progression check portion of the action. The action will no longer check that the previous version of the submodule is an ancestor of the new version. Allows the action to be used only for branch checking.

Outputs

fails

The reason the action failed (if any). The check will stop at the first failure. In case of an error, fails will equal "error"

Usage

To add to a repo create a workflow file (such as .github/workflows/check-submodules.yml) with the following content adjusted for your needs. Note that the step to checkout the submodule is only required for private submodules.

name: check-submodule

on: [push, pull_request]

jobs:
  check-submodules:
    name: Check Submodule
    runs-on: ubuntu-latest
    steps:
    - name: Checkout this repo
      uses: actions/checkout@v3
    ## Step only reqired for private submodules
    - name: Checkout submodule repo
      uses: actions/checkout@v3
      with:
        repository: UserOrg/RepoName
        path: "path/to/repo"
        token: ${{ secrets.PAT_for_Private_Submodule }}
    - name: Check Submodule Name
      uses: jtmullen/submodule-branch-check-action@v1
      with:
        path: "path/to/submodule"
        branch: "main"
        first_parent: true
        fetch_depth: "50"
        pass_if_unchanged: true
        require_head: true
		disable_progression: true

Usage Notes

To ensure this action runs correctly you must checkout the current repo. If the submodule is private, you must also check out the submodule repo, in the correct location. As shown above, the Github Checkout Action is a good way to set this up. Below are the main requirements for doing so:

Fetch Depth: This action handles the fetch depth for both the parent repo and submodule. If you are restricting the fetch depth in this action be sure to pay attention to the default in your checkout method - you may need to restrict it there as well for the desired effect.

Token: If your submodule is private, provide a personal access token with repo level access for the submodule so it can be checked out. If not using the first party GitHub Checkout Action, ensure your method also persists the token so this action can access the remote repo.

Path: Leave the repo the action is run on at the default location, checkout the submodule into its appropriate location within the repo.

You can also see where this is used

Note: this was developed for several private repos so many uses will not be listed above

submodule-branch-check-action's People

Contributors

jamiesandenr avatar jtmullen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

submodule-branch-check-action's Issues

Error if submodule and this action added in the same PR

If I add a submodule and this action in the same PR, the check fails since it tries to check out the submodule on master/main as well to calculate how the submodule changed:

__Line:66__Error: Could not checkout submodule hash referenced by master (is it pushed to remote?)

A workaround is to first add the submodule, then add the check in a separate PR.

It would be nice if the action could say something like “new submodule” in this case. Or at least document this gotcha.

Pathspec null passes since it is "unchanged"

Run for PR # null of null into null on jtmullen/b-fw
submodule.mbed.path
error: pathspec 'null' did not match any file(s) known to git
Submodule 'mbed' (https://github.com/IlliniSolarCar/mbed.git) registered for path 'mbed'
Submodule path 'mbed': checked out 'e73a84fc9b24369161c61a88c12463a636181fab'
Switch to submodule at: mbed
error: pathspec 'null' did not match any file(s) known to git
Submodule mbed Changed from: e73a84fc9b24369161c61a88c12463a636181fab to e73a84fc9b24369161c61a88c12463a636181fab
Check for submodule on branch master
  origin/master
Submodule is on branch master
Check if submodule unchanged from null
PASS: mbed is unchanged from null

Action not fails when older submodule is pushed

Github Action has this as a first line submodule-branch-check-action

A github action to ensure that a submodule is progressing to a child of the previous version (or not changing) and that the new submodule version is on a specific branch (optional).

I would expect that Action fail PR check if in PR used older submodule version.

I'm not sure if it's documentation problem or an error, but I find it confusing as my test shows opposite:

# in submodule
git checkout HEAD~1

# in main repo
git cm "on master but older commit"

# Github Action PASS (expected to fail)

In output only last 2 lines are confusing:

Run for PR # 2320 of integrate-check-submodule-workflow into develop on TangleInc/TangleBack
Checkout Branch Histories
Full Brach Histories
From TangleInc/TangleBack
 * branch              integrate-check-submodule-workflow -> FETCH_HEAD
From TangleInc/TangleBack
 * branch              develop    -> FETCH_HEAD
submodule.submodules/release_tool.path
M	submodules/release_tool
Switched to branch 'integrate-check-submodule-workflow'
Your branch is up to date with 'origin/integrate-check-submodule-workflow'.
Submodule 'submodules/release_tool' ([email protected]:TangleInc/release-tool.git) registered for path 'submodules/release_tool'
Submodule path 'submodules/release_tool': checked out '9a5ffbcb037e9788559bf6d80b2f687435d107c5'
Switch to submodule at: submodules/release_tool
Switched to branch 'develop'
M	submodules/release_tool
Your branch is up to date with 'origin/develop'.
Submodule path 'submodules/release_tool': checked out '1be4e947292e53c8d1e8638e4a9baa75e482977b'
Submodule submodules/release_tool Changed from: 1be4e947292e53c8d1e8638e4a9baa75e482977b to 9a5ffbcb037e9788559bf6d80b2f687435d107c5

Check if submodule has been changed on integrate-check-submodule-workflow
grep: ...
PASS: Submodule submodules/release_tool has not been changed on branch integrate-check-submodule-workflow
...
# other changed files (not related to submodule)
...
submodules/release_tool: No such file or directory

Checkout by hash, instead of branch, on PR

Currently, if you re-run a check for a previous commit on a PR it actually runs for the most recent version because this checks out based on branch name, not the commit.

Check for not pushed submodule

When I was checking this workflow (in private repo) I did this:

#
# Test 1
#

# in submodule
release_tool git:(master) > git checkout -b another_branch
release_tool git:(another_branch) > git c --allow-empty -m "empty"
# FORGOT TO PUSH THIS COMMIT!

# in main repo
repo git:(integrate-check-submodule-workflow) > git cm "another branch but not pushed commit"  && git push

# GitHub Action: PASS! (should FAIL)

#
# Test 2
#

# in submodule
release_tool git:(another_branch) > git push

# in main repo (make separate commit for verbosity)
repo git:(integrate-check-submodule-workflow) > git c --allow-empty -m "now submodule commit is pushed"  && git push

# GitHub Action: FAIL (expected)

output:


Run for PR # 2320 of integrate-check-submodule-workflow into develop on TangleInc/TangleBack
Checkout Branch Histories
Full Brach Histories
From TangleInc/TangleBack
 * branch              integrate-check-submodule-workflow -> FETCH_HEAD
From TangleInc/TangleBack
 * branch              develop    -> FETCH_HEAD
submodule.submodules/release_tool.path
Switched to branch 'integrate-check-submodule-workflow'
M	submodules/release_tool
Your branch is up to date with 'origin/integrate-check-submodule-workflow'.
Submodule 'submodules/release_tool' ([email protected]:TangleInc/release-tool.git) registered for path 'submodules/release_tool'
fatal: remote error: upload-pack: not our ref 1ec918928494ac0c0f5bca1d1ec03dd71113d194
fatal: the remote end hung up unexpectedly
Fetched in submodule path 'submodules/release_tool', but it did not contain 1ec918928494ac0c0f5bca1d1ec03dd71113d194. Direct fetching of that commit failed.
Switch to submodule at: submodules/release_tool
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
Submodule submodules/release_tool Changed from: 1be4e947292e53c8d1e8638e4a9baa75e482977b to 1be4e947292e53c8d1e8638e4a9baa75e482977b
Check if submodule has been changed on integrate-check-submodule-workflow
grep: ...
# other changed files (not related to submodule)
...
PASS: Submodule submodules/release_tool has not been changed on branch integrate-check-submodule-workflow

How I understand it:

If you want to add this check, then before you check current submodule branch against base branch you need to check that your local submodule branch is what it should be.
This command will always give commit sha recorded in git and not just a sha of local version (SO explanation)

git ls-tree HEAD {SubmodulePath}

# in my case
repo > cd submodules/release_tool

release_tool > git rev-parse HEAD
1be4e947292e53c8d1e8638e4a9baa75e482977b

# make changes in local version and `git rev-parse HEAD` will get new sha
release_tool > git checkout HEAD~1
release_tool > git rev-parse HEAD
9a5ffbcb037e9788559bf6d80b2f687435d107c5

# git ls-tree will still provide commited sha
release_tool > cd -
repo > git ls-tree HEAD submodules/release_tool
160000 commit 1be4e947292e53c8d1e8638e4a9baa75e482977b	submodules/release_tool

Code is on previous commit after action is complete

After the action completes its check, the repository is not checked out to the commit merged on non-PR branches. It should at the very end of the check, checkout back to the commit merged. Our use case is after the check is complete, we build a Java JAR from the branch merged and package it into a Docker container.

Check fails when submodule path differs from submodule name

Currently the check at

SUBMODULES=`git config --file .gitmodules --name-only --get-regexp path`
echo "${SUBMODULES}" | grep ".${INPUT_PATH}." || error "Error: path \"${INPUT_PATH}\" is not a submodule on ${TO_HASH}"

and
BASESUBMODULES=`git config --file .gitmodules --name-only --get-regexp path`
echo "${BASESUBMODULES}" | grep ".${INPUT_PATH}." || newSubmoduleWarning "${INPUT_PATH}"

is incorrect---instead of checking if the path given to the action is the path of a submodule this checks if the path given is in the name of the key corresponding to the path. This happens to work in the event that the submodule is named the same (which is a common case), but breaks when it is not.

For instance, this can be reproduced with a structure like the following:

repo-root
├── .gitmodules
├── main-repo-content
└── submodule-dir
   ├── .git
   └── submodule-content

where .gitmodules is as follows:

[submodule "submodule"]
	path = submodule-dir
	url = <arbitrary> 

which can be replicated by adding the submodule like so: git submodule add --name submodule -- $URL submodule-dir

Then a workflow like

  check-submodules:
    name: check submodule branches
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Check submodules
        uses: jtmullen/submodule-branch-check-action@v1
        with:
          path: submodule-dir
          branch: master

results in an error like

Error: path "submodule-dir" is not a submodule on $COMMIT

Action not work with tags on base repo

Hi! In my scenario I want to trriger action with tags, so I'm doing:
git tag v0.0.6
git push origin my-branch --tags
then my workflow starts and throw error at:

Get Submodule Info
 Submodule path 'webapp': checked out '63ad3d11bb8......'
  Full Submodule History
  fatal: reference is not a tree: 0000000000000000000000000000000000000000
  Error: __Line:125__Error: Could not checkout 0000000000000000000000000000000000000000

its probably caused by:

  Setup
  Run for push of refs/tags/v0.0.6 from 0000000000000000000000000000000000000000 to 7b98b541253e5dd3f79cfa...... on ORG/RepoName by urbaned121

my workflow is:

  name: Docker images

# Run this Build for all pushes to 'deployment-changes' or develop branch, or tagged releases.
# Also run for PRs to ensure PR doesn't break Docker build process
on:
  push:
    branches:
#      - my-branch
      - develop
    tags:
      - 'v**'
 
    steps:

      - name: Checkout codebase
        uses: actions/checkout@v4
        with:
          ref: my-branch

      - name: Checkout submodule repo
        uses: actions/checkout@v4
        with:
          repository: MySubRepo/webapp
          path: webapp
          token: ${{ secrets.PAT }}
      - name: Check Submodule Name
        uses: jtmullen/[email protected]
        with:
          path: webapp
          branch: deployment-changes
          first_parent: true
          fetch_depth: "1"
          pass_if_unchanged: true
          require_head: true
          disable_progression: true

      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v3
        
        ..... 
 

Action works well with pushes to my-branch but not work with tags
Is there any solution or workaround?
Why I need it?
I need to use tags later in my action to tag my docker images

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.