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

Unable to download artifacts uploaded with upload-artifact@v4 #1790

Closed
gsmet opened this issue Feb 10, 2024 · 3 comments · Fixed by #1791
Closed

Unable to download artifacts uploaded with upload-artifact@v4 #1790

gsmet opened this issue Feb 10, 2024 · 3 comments · Fixed by #1791

Comments

@gsmet
Copy link
Contributor

gsmet commented Feb 10, 2024

GitHub published a new version of upload-artifact, v4: https://github.com/actions/upload-artifact .
It is supposed to be a lot better, most notably faster and more flexible.

I tried to use it and unfortunately, we hit an issue:

2024-02-09 18:36:28,471 ERROR [io.qua.bot.bui.git.BuildReportsUnarchiver$ArtifactIsDownloaded] (awaitility-thread) Pull request #166 - Unable to download artifact build-reports-JVM Tests - JDK 17 - windows-latest- retry #5: org.kohsuke.github.HttpException: <?xml version="1.0" encoding="utf-8"?>
<Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:dfb418bf-301e-007c-297e-5b6ca7000000
Time:2024-02-09T17:36:28.4208458Z</Message></Error>
	at org.kohsuke.github.GitHubConnectorResponseErrorHandler$1.onError(GitHubConnectorResponseErrorHandler.java:62)
	at org.kohsuke.github.GitHubClient.detectKnownErrors(GitHubClient.java:504)
	at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:464)
	at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:427)
	at org.kohsuke.github.Requester.fetchStream(Requester.java:131)
	at org.kohsuke.github.GHArtifact.download(GHArtifact.java:125)

I stumbled upon arduino/report-size-deltas#83 which seems to indicate that we shouldn't send the Authorization header to the download URL.
Unfortunately, my guess is that the Java HTTP Client is not flexible enough for that and is sending the Authorization header anyway.
It's not possible to configure the redirect behavior at the request level either so that's a bit problematic.

I'm not completely sure how to solve this (or even if my diagnostic is the correct one...).

@gsmet
Copy link
Contributor Author

gsmet commented Feb 12, 2024

I have a working patch... can't say it was easy...

gsmet added a commit to hub4j-test-org/GHWorkflowRunTest that referenced this issue Feb 12, 2024
gsmet added a commit to gsmet/github-api that referenced this issue Feb 13, 2024
The artifacts upload by actions/upload-artifact@v4 are hosted on a new
infrastructure which has several constraints:
- we will have an error if we push the Authorization header to it, which
  was the case when using the Java 11 HttpClient (and is considered a
  bad practice so it is good to have fixed it anyway)
- the host name is dynamic so our test infrastructure was having
  problems with proxying the request

All these problems are sorted out by this pull request and we are now
testing an artifact uploaded by v3 and one uploaded by v4.

Fixes hub4j#1790
@zakkak
Copy link

zakkak commented Mar 6, 2024

We are seeing a similar issue but in our case it's not related to the upload-artifact action, but to accessing run logs.

See graalvm/mandrel#687

Reproducer

  1. Create a file Main.java with the following content:
//usr/bin/env jbang "$0" "$@" ; exit $?

//DEPS org.kohsuke:github-api:1.319

import org.kohsuke.github.*;
import org.kohsuke.github.function.InputStreamFunction;

import java.io.IOException;
import java.io.UncheckedIOException;
import java.io.BufferedReader;
import java.io.InputStreamReader;

class Main {

    private static String token;

    private static String thisRepo;

    private static String runId;

    private static InputStreamFunction<String> getLogArchiveInputStreamFunction(String... filters) {
        return (is) -> {
            StringBuilder stringBuilder = new StringBuilder();
            try (BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(is))) {
                String line;
                while ((line = bufferedReader.readLine()) != null) {
                    stringBuilder.append(line);
                    stringBuilder.append(System.lineSeparator());
                }
            }
            return stringBuilder.toString();
        };
    }

    public static void main(String... args) {
        thisRepo = args[0];
        runId = args[1];
        if (args.length > 2) {
            token = args[2];
        }
        else {
            token = System.getenv("GITHUB_TOKEN");
        }
        try {
            final GitHub github = new GitHubBuilder().withOAuthToken(token).build();
            final GHRepository workflowRepository = github.getRepository(thisRepo);
            GHWorkflowRun workflowRun = workflowRepository.getWorkflowRun(Long.parseLong(runId));
            PagedIterable<GHWorkflowJob> listJobs = workflowRun.listJobs();
            listJobs.forEach(job -> {
                try {
                    System.out.println(job.downloadLogs(getLogArchiveInputStreamFunction()));
                } catch (IOException e) {
                    throw new UncheckedIOException(e);
                }
            });
        }
        catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }
}

2.Run with:

jbang ./Main.java hub4j/github-api 8119280581 [your_gh_token]

@gsmet
Copy link
Contributor Author

gsmet commented Mar 7, 2024

@zakkak yeah, I checked the URLs and they are using the same infrastructure as upload-artifact@v4 for the logs, thus why we have the same issue.

bitwiseman added a commit that referenced this issue Mar 9, 2024
* Add support for artifacts uploaded by actions/upload-artifact@v4

The artifacts upload by actions/upload-artifact@v4 are hosted on a new
infrastructure which has several constraints:
- we will have an error if we push the Authorization header to it, which
  was the case when using the Java 11 HttpClient (and is considered a
  bad practice so it is good to have fixed it anyway)
- the host name is dynamic so our test infrastructure was having
  problems with proxying the request

All these problems are sorted out by this pull request and we are now
testing an artifact uploaded by v3 and one uploaded by v4.

Fixes #1790

* Add support for Git longpaths on Windows CI

* Update src/main/java11/org/kohsuke/github/extras/HttpClientGitHubConnector.java

* Move redirect handling to GitHubClient

* WIP

* Make snapshot file names based on mapping file information

* For redirect host is only same if ports are also same

* Delete .vscode/launch.json

* Verify removal of header when redirecting

---------

Co-authored-by: Liam Newman <bitwiseman@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants