Couldn’t you refer directly to the submodule repo (or a directory in it) with the uses: keyword? That way the submodule wouldn’t have to be checked out first, or at least not to run the action. 🙂

The only disadvantage I see is that if the submodule HEAD has to exactly match the action ref you’ll have to update both at the same time.

Thanks @airtower-luna.
Actually the real problem is, in our company with Github Enterprise, admins have disabled the use of public actions by restricting to use only local actions, i.e actions which are inside our organization.

More Info:

Screenshot 2020-10-29 at 9.05.33 AM1350×692 58.6 KB

To be frank, we can bypass this check by committing whole action code/repo as part of our application repo, but thought sub-module approach would be neater.
Also we can clone required actions repo into our organization, etc. (Which we don’t have enough privilage to do 🤣 )

PS: I understand that, it is not good to by pass this check in any way unless we get approval from admins 😊 😉

You need to checkout with submodules:

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
        with:
          submodules: recursive
      - name: Use submodule action
        uses: ./.github/actions/checkout
        with:
          ...

See https://github.com/actions/checkout:

Whether to checkout submodules: true to checkout submodules or recursive to recursively checkout submodules. Default: false

Yes @Simran-B.

But uses: actions/checkout@v2 itself fails as this is public repo outside organization.
As shared above, our admins have restricted to use only local actions.
Hence I was trying to add this repo: actions/checkout as sub-module to our internal repo.

Let me know if this clarifies.

Thanks

We think it would be a good idea when the checkout action supports clonimng private submouldes by providing a different SSH key. The PAT token is not owrking in many cases since it is bounded to a specific user. With a SSH key pair you can clone the repo as submodule by setting up a deploy key. actions/checkout#287

Sorry, I misunderstood the problem. The easiest solution would indeed be to allow Actions by GitHub:

(I wonder if local actions need to be added to the allowlist if Allow select actions is enabled…)

Workaround is to check-in the whole action code in the path

Actually no. It’s a chicken and egg problem. The runner starts out with a fresh virtual environment. You want to checkout the repo using a local copy of the checkout action, but it doesn’t exist - you first need to checkout the repo… The runner seems to retrieve public actions automatically, so that the workflow run can be bootstrapped by fetching actions/checkout and using it to checkout the repo. Using any means provided by the virtual environment to retrieve at least the checkout action seems to be unavoidable. You could fork the official repo if the code has to be within your own org too.

Weird, if I fetch the three core files of the checkout action with curl, I can use it as local action to checkout a repo. However, the following errors occur when .temp/checkout is run:

Error: Unable to process command ‘::add-matcher::/home/runner/work/olive-ci/olive-ci/temp/checkout/dist/problem-matcher.json’ successfully.

Error: Unable to process command ‘::add-matcher::/home/runner/work/test-ci/test-ci/temp/checkout/dist/problem-matcher.json’ successfully.

Error: Could not find a part of the path ‘/home/runner/work/test-ci/test-ci/temp/checkout/dist/problem-matcher.json’.

With continue-on-error: true it will simply be ignored and the checkout does work! But there is another error in Post checkout repository (what the heck?)

Error: Can’t find ‘action.yml’, ‘action.yaml’ or ‘Dockerfile’ under ‘/home/runner/work/test-ci/test-ci/temp/checkout’. Did you forget to run actions/checkout before running your local action?

BTW. local actions do not need to be added to the allowlist. And it’s not limited to the very repo, it can be any repo in the same account / organization.

I was thinking, github runners clone actions repo before running them.

uses:action/repo

Can’t they clone submodules in the repo as well?

git clone --recurse-submodules <action/repo.git>

Is that a bad feature request?

Thanks

Huh. Local action means an action whose repository is in the same user account or org. It’s not restricted to the very repository. That means, you can simply fork actions/checkout and use it in your workflow like uses: {your-org}/checkout@v2. No need to add this action as submodule. You can then checkout the repo with submodules to use any of the actions you added as submodules.

As I said above we are dependent on our admins for this too.

Also we can clone required actions repo into our organization, etc. (Which we don’t have enough privilage to do 🤣 )

Ah, I didn’t read that as forking. Well, if they don’t give you enough permissions, how are you supposed to do your job? If they don’t trust you as employee, then they shouldn’t trust GitHub or other cloud services either and go for something on-premise.

Thanks everyone.

I’ll share this thread with admins and hopefully I’ll be able to pursued them to realise the silliness of disabling public action and remove this blocker.

Thanks