Skip to content

Newly created Go extensions using standard workflow template fail due to older cli/gh-extension-precompile action and Android builds #10084

Closed

Description

@andyfeller

Describe the bug

With the v2 major release of cli/gh-extension-precompile addressing build issues with more recent Go releases on Android in cli/gh-extension-precompile#56, the release workflow templates used by gh ext create should be updated as the v1 version causes Go extensions to break.

$ gh --version
gh version 2.62.0 (2024-11-14)
https://github.com/cli/cli/releases/tag/v2.62.0

jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: cli/gh-extension-precompile@v1
with:
generate_attestations: true
go_version_file: go.mod

jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: cli/gh-extension-precompile@v1
with:
build_script_override: "script/build.sh"

Steps to reproduce the behavior

  1. Create standard Go extension

    gh ext create --precompiled=go foobar
  2. Create repository based on local repository

    cd gh-foobar
    gh repo create gh-acceptance-testing/gh-foorbar --private --push --source .
  3. Create release

    gh release create v0.0.1 --title v0.0.1 --generate-notes
  4. Confirm release workflow fails due to Android CGO

    gh run view "$(gh run list --json databaseId --jq '.[0].databaseId')" --log-failed

    resulting in:

    android/amd64 requires external (cgo) linking, but cgo is not enabled
    Error: Process completed with exit code 1.

Expected vs actual behavior

I expect newly created extensions to be releasable from an unmodified standard release workflow with current Go releases.

Activity

  1. williammartin commented on Dec 16, 2024

    @williammartin
    Member

    Thanks for the detailed report, seems pretty clear to me.

    Acceptance Criteria

    Given I have used gh ext create --precompiled=go to create a new extension
    When I create a new release based on the newly created extension
    Then the gh-extension-precompile workflow should succeed

  2. added
    priority-3Affects a small number of users or is largely cosmetic
    and removed on Dec 16, 2024
  3. jsoref commented on Jan 6, 2025

    @jsoref
    Contributor

    @andyfeller: your steps to reproduce were almost perfect, but they don't work for me and I don't think they'd work for most people. Specifically this --private flag in:

    gh repo create gh-acceptance-testing/gh-foorbar --private --push --source .
    

    creates a private repository, and private repositories don't have attestations:write unless someone pays for an enterprise plan.

    For anyone trying to validate this issue, they should use:

    gh repo create gh-foobar --push --source .
    

    instead.

    Also note that it isn't clear why the repository name was gh-foorbar instead of gh-foobar -- that was very confusing.

  4. andyfeller commented on Jan 7, 2025

    @andyfeller
    ContributorAuthor

    @andyfeller: your steps to reproduce were almost perfect, but they don't work for me and I don't think they'd work for most people. Specifically this --private flag in:

    I guess you could say my steps were 😎 prefect 🥁 ... seriously, I'd chalk it up to that mysterious way that r gets added to things and I was a little careless. Thanks for the contribution, @jsoref! ❤

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinggh-extensionrelating to the gh extension commandgood first issuehelp wantedContributions welcomepriority-3Affects a small number of users or is largely cosmetic

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions