Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go Autobuild failure reason unclear #16469

Closed
arsenetar opened this issue May 10, 2024 · 2 comments · Fixed by #16480
Closed

Go Autobuild failure reason unclear #16469

arsenetar opened this issue May 10, 2024 · 2 comments · Fixed by #16480
Assignees
Labels
acknowledged GitHub staff acknowledges this issue Go question Further information is requested

Comments

@arsenetar
Copy link

*Go auto-build failure reason is unclear and debug logging does not provided additional details.

I am running CodeQL in a repository where the go project is in a sub-directory. The repo also has a go.work file in the root. The CodeQL analysis appears to be "working" with autobuild, however the log is outputting: Build failed, continuing to install dependencies., re-running with debug enabled does not increase the details around that. The following go get and analysis both seem to work as expected.

With context (slightly sanitized):

2024/05/10 19:58:00 Autobuilder was built with go1.22.2, environment has go1.22.2
2024/05/10 19:58:00 LGTM_SRC is /home/runner/work/repo/repo
2024/05/10 19:58:00 Found go.work file(s) in: go.work.
2024/05/10 19:58:00 Loading go.work...
2024/05/10 19:58:00 go.work uses the following Go modules: operator/go.mod
2024/05/10 19:58:00 Found 1 go.mod file(s).
2024/05/10 19:58:00 Import path is 'github.com/org/repo'
2024/05/10 19:58:00 Build failed, continuing to install dependencies.
2024/05/10 19:58:00 Installing dependencies using `go get -v ./...` in `operator`.

The docs at https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages#building-go seem to imply it will attempt to invoke make, there is a functional Makefile in the subdirectory, so that should work for the build (my first thought was maybe the make command was failing but no actual output is available). It seems like it fell back to the second option in the docs. In the meantime I am going to try validating there is not an issue with the Makefile when run in this environment but it "should" be functional here (the go build command within the Makefile at least does work as expected in this environment as I validated that when switching to manual build).

The two items I have for this issue are:

  1. Does failure to build and falling back to the later option degrade the results?
  2. Is it possible to have better output as to why the build failed?
@arsenetar arsenetar added the question Further information is requested label May 10, 2024
@mbg
Copy link
Member

mbg commented May 13, 2024

Hi @arsenetar 👋

Thanks for asking this question. The message in the log probably isn't anything to worry about here. I agree that it needs to be better worded. I'll see if we can get this reworded to be more accurate.

The documentation you found mostly does explain what's going on. The autobuilder couldn't find a build script (such as a Makefile) in the root of the repository, but it then proceeds with an ordinary Go build in your project's subdirectory, which seems to work fine for you. The log message is worded the way it is for historical reasons and no longer accurately reflects what happened.

In terms of the Makefile in the subdirectory, we should probably be invoking that for consistency, but this isn't happening due to a bug that was reported to us last week. We are in the process of addressing that. Once that's addressed, your Makefile should also be used.

@mbg mbg self-assigned this May 13, 2024
@mbg mbg added acknowledged GitHub staff acknowledges this issue Go labels May 13, 2024
@mbg
Copy link
Member

mbg commented May 13, 2024

I have opened #16480 which improves the wording of the log messages for now, and the improvements to which scripts are run will come later as part of the bug fix mentioned above.

Once the PR is merged, this issue will be closed. If you have further questions and the issue is closed, feel free to re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged GitHub staff acknowledges this issue Go question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants