-
Bug
-
Resolution: Fixed
-
Low
-
None
-
5
-
Severity 3 - Minor
-
1
-
Steps to reproduce
- Create a build with 2 stages, 1 of them a final stage.
- In the first stage, add N jobs that generate an artifact.
- Each job should generate an artifact:
- Make them search for */.log or something.
- Untick "required".
- Create a task in the job that generates a "log" file (let's call it "job-with-no-log").
- Update one of the jobs to not output any log files at all (so that the artifact will fail to generate).
- Create a job in the final stage that will collect all of the log files from all of the artifacts and concatenate them together.
- You should use artifact subscriptions for this.
- Run the build.
Expected results
The final stage's task will execute successfully when one of the configured shared artifacts is absent.
Actual results
Failure in artifact preparation phase during processing of: Subscription for Non required shared artifact: [job-with-no-log], pattern: [**/*.log], destination: [input] 1 error(s) found when performing pre-build actions.
My notes
- The wording of the error message in the final stage's build logs is confusing. If the artifact was "non required", why did the build fail?
- The "Required" checkbox for artifacts states that "Build fails if the artifact cannot be published." However, the job that generates the artifact actually does fail? That's a mismatch of expectations
Bamboo seems to be torn between making builds fail loudly vs. allowing builds to continue when some data is absent. My expectation was that by unticking "required" on an artifact definition, any subsequent subscriptions to that artifact would work (as in, silently ignore the non-existence of it). It seems the Bamboo team's thinking does not match mine. I can appreciate that the intention is probably that builds fail if "unexpected" things happen, but this artifact is definitely optional as far as my build is concerned; it can cope just fine without it and I would expect the build to pass accordingly.
I'd be interested in workarounds, but I'd also be keen to see the behaviour (or at least the wording) become less confusing.