timja
commented
2 years ago I’ve seen this before but never been able to reliably introduce, that’s why I added the must not be null bit to make it easier to track down
Closed Highsight closed 1 year ago
timja
commented
2 years ago I’ve seen this before but never been able to reliably introduce, that’s why I added the must not be null bit to make it easier to track down
Highsight
commented
2 years ago It is a fairly reliable issue for us, to the point where we almost couldn't use the plugin. With this one, I'm not entirely sure where actualContainer needs to be set to be 100% safe, but having it in the Constructor and in root() seems to have completely solved the issue for us.
Great plugin btw, my ability to repair it on my end is a testament to how well it's maintained!
jisenberg
commented
2 years ago This issue is a problem for us as well. This fixed it for us, but I don't know enough about the code to say whether it is correct.
diff --git a/src/main/java/com/microsoft/jenkins/artifactmanager/AzureArtifactManager.java b/src/main/java/com/microsoft/jenkins/artifactmanager/AzureArtifactManager.java
index ecfb999..dd4d4bf 100644
--- a/src/main/java/com/microsoft/jenkins/artifactmanager/AzureArtifactManager.java
+++ b/src/main/java/com/microsoft/jenkins/artifactmanager/AzureArtifactManager.java
@@ -383,6 +383,17 @@ public final class AzureArtifactManager extends ArtifactManager implements Stash
@Override
public VirtualFile root() {
+ if (actualContainerName == null) {
+ try {
+ getActualContainerName(null);
+ } catch (IOException e) {
+ // TODO Auto-generated catch block
+ e.printStackTrace();
+ } catch (InterruptedException e) {
+ // TODO Auto-generated catch block
+ e.printStackTrace();
+ }
+ }
return new AzureBlobVirtualFile(this.actualContainerName, getVirtualPath("artifacts"), build);
}
Minreaux
commented
1 year ago We are getting this error reliably in our setup as well (environment attached above). In our scenario, the error is simply adding "null" to the beginning of the first folder after the container, but it isn't failing to actually archive any of the artifacts to the Azure Blob storage.
For example, if we put all of our artifacts in the "jenkins" container in the blob storage to jenkins/exampleFolder/examplePipeline/exampleArtifact1. Then the builds are chugging along archiving artifacts until eventually this error is hit and the blob storage path starts uploading the artifacts to jenkins/nullexampleFolder/examplePipeline/exampleArtifact2.
As far as I can tell, it happens intermittently and there is no specific way for us to trigger it through repro steps. The same pipeline without any changes uploads without issue, then this error is eventually hit, and it starts uploading to the null\<path> instead of just \<path> which unfortunately breaks our artifact retrieval from the blob.
I can fix the issue by deleting the entire pipeline and re-creating it or discarding all of the old artifacts and starting from scratch, but eventually it comes back and once the error is hit, it never goes away and always uploads to the null\<path>, at least as far as we've experienced.
Minreaux
commented
1 year ago I created a custom version of the plugin using the fix suggested by @jisenberg and while it initially appeared to fix the issue, the null\<path> eventually came back for the artifacts.
Minreaux
commented
1 year ago Previously we were not using the "Base Prefix (Optional)" option. I eventually noticed that the null we were seeing was in the same place as the base prefix would be. I changed it so that we are now using a base prefix and I've had artifacts getting stored in the Azure blob for about a week now and this issue hasn't come back.
@timja Based on these findings, I think the "Base Prefix" optional option, is not actually optional and is most likely the cause of this issue. Hope this helps others who may be encountering the same problem.
timja
commented
1 year ago Interesting, I'll try check it
timja
commented
1 year ago I think this PR will solve the issue: https://github.com/jenkinsci/azure-artifact-manager-plugin/pull/47
I can't reliably reproduce the issue but if I spam enough builds normally at least one of them hit it.
I believe it's a race condition, which can be easily avoided by explicitly setting this in the artifact manager constructor and when loaded from disk (via onLoad)
Anyone able to test it out and provide feedback?
Jenkins and plugins versions report
Environment
```text Jenkins: 2.319.1 OS: Windows NT (unknown) - 10.0 --- Office-365-Connector:4.15.2 abort-downstream-builds:1.0 ace-editor:1.1 active-directory:2.25 analysis-model-api:10.8.1 ansicolor:1.0.1 ant:1.13 antisamy-markup-formatter:2.5 apache-httpcomponents-client-4-api:4.5.13-1.0 authentication-tokens:1.4 authorize-project:1.4.0 azure-artifact-manager:97.v074e1332e88d azure-sdk:70.v63f6a95999a7 badge:1.9 blueocean-commons:1.25.2 blueocean-rest:1.25.2 bootstrap4-api:4.6.0-3 bootstrap5-api:5.1.3-3 bouncycastle-api:2.25 branch-api:2.7.0 build-name-setter:2.2.0 build-symlink:1.1 build-timeout:1.20 build-timestamp:1.0.3 buildgraph-view:1.8 caffeine-api:2.9.2-29.v717aac953ff3 checks-api:1.7.2 cloudbees-folder:6.16 cobertura:1.17 code-coverage-api:2.0.4 command-launcher:1.6 conditional-buildstep:1.4.1 copyartifact:1.46.2 cppcheck:1.25 credentials:2.6.2 credentials-binding:1.27 dark-theme:155.v497c78bbdbb3 dashboard-view:2.18 data-tables-api:1.11.3-4 display-url-api:2.3.5 docker-commons:1.17 docker-workflow:1.26 durable-task:493.v195aefbb0ff2 dynamic_extended_choice_parameter:1.0.1 echarts-api:5.2.2-1 email-ext:2.86 embeddable-build-status:2.0.3 envinject:2.4.0 envinject-api:1.8 extended-choice-parameter:0.82 external-monitor-job:1.7 flexible-publish:0.16.1 font-awesome-api:5.15.4-4 forensics-api:1.7.0 git:4.10.1 git-client:3.10.0 git-server:1.10 github:1.34.1 github-api:1.301-378.v9807bd746da5 github-branch-source:2.11.3 greenballs:1.15.1 groovy:2.4 groovy-label-assignment:1.2.0 groovy-postbuild:2.5 handlebars:3.0.8 jackson2-api:2.13.0-230.v59243c64b0a5 javadoc:1.6 jaxb:2.3.0.1 jdk-tool:1.5 jjwt-api:0.11.2-9.c8b45b8bb173 jobConfigHistory:2.28.1 jquery:1.12.4-1 jquery-detached:1.2.1 jquery3-api:3.6.0-2 jsch:0.1.55.2 junit:1.53 ldap:2.7 lockable-resources:2.12 log-parser:2.1 mailer:1.34 mapdb-api:1.0.9.0 matrix-auth:2.6.11 matrix-project:1.19 maven-plugin:3.15.1 momentjs:1.1.1 msbuild:1.30 multiple-scms:0.8 naginator:1.18.1 nodelabelparameter:1.10.1 okhttp-api:4.9.3-105.vb96869f8ac3a pam-auth:1.6.1 parameterized-trigger:2.42 permissive-script-security:0.7 pipeline-build-step:2.15 pipeline-github-lib:1.0 pipeline-graph-analysis:1.12 pipeline-input-step:427.va6441fa17010 pipeline-milestone-step:1.3.2 pipeline-model-api:1.9.3 pipeline-model-definition:1.9.3 pipeline-model-extensions:1.9.3 pipeline-rest-api:2.19 pipeline-stage-step:2.5 pipeline-stage-tags-metadata:1.9.3 pipeline-stage-view:2.19 plain-credentials:1.7 plugin-util-api:2.6.0 popper-api:1.16.1-2 popper2-api:2.10.2-1 powershell:1.7 preSCMbuildstep:0.3 prism-api:1.25.0-1 promoted-builds:3.11 rebuild:1.32 resource-disposer:0.16 role-strategy:3.2.0 run-condition:1.5 scm-api:2.6.5 script-security:1.78 shelve-project-plugin:3.2 simple-theme-plugin:0.7 snakeyaml-api:1.29.1 ssh-credentials:1.19 sshd:3.1.0 structs:308.v852b473a2b8c subscribe-build:0.99 subversion:2.15.1 theme-manager:0.6 throttle-concurrents:2.5 timestamper:1.15 token-macro:267.vcdaea6462991 trilead-api:1.0.13 validating-string-parameter:2.8 warnings-ng:9.10.2 windows-azure-storage:365.vf41653c43b01 windows-slaves:1.8 workflow-aggregator:2.6 workflow-api:1105.v3de5e2efac97 workflow-basic-steps:2.24 workflow-cps:2644.v29a793dac95a workflow-cps-global-lib:552.vd9cc05b8a2e1 workflow-durable-task-step:1102.v9c8d2f466adb workflow-job:2.42 workflow-multibranch:2.26 workflow-scm-step:2.13 workflow-step-api:613.v375732a042b1 workflow-support:3.8 ws-cleanup:0.40-SNAPSHOT (private-c04a2409) ```What Operating System are you using (both controller, and any agents involved in the problem)?
Windows Server 2019
Reproduction steps
Expected Results
You should be able to see the archived artifacts in the job.
Actual Results
The archived artifacts do not show in the job. An error is thrown in the Jenkins log:
Anything else?
The issue here is "actualContainer" in AzureArtifactManager does not always get initialized. The solution I've found for this is to call getActualContainerName() in the AzureArtifactManager constructor AND in root(), which helps ensure that "actualContainer" is set when it's expected to be used. (It may only be needed in one place, this is just what I did to get it working).