Are optional artifacts possible ?

[Pat McGrath]

I have a pipeline that creates artifacts, one of which is a list of directories that are not always generated, so my job's artifact entry looks like

    <artifact src="**/*.Tests/bin/Release" dest="build" />

this job will fail if the job does not create some content that matches the artifact src attribute, it gives me the following message

    The rule [**/*.Tests/bin/Release] cannot match any resource under [pipelines\APipeline]

    .....

    Uploading finished. Failed to upload [**/*.Tests/bin/Release]

So it seems unless you generate content the job will fail, is it possible to indicate that the artifact is optional ?

Thanks in advance

Pat

[Aravind SV]

On Thu, Jun 25, 2015 at 7:19 AM, Pat McGrath <pmcg...@gmail.com> wrote:

So it seems unless you generate content the job will fail, is it possible to indicate that the artifact is optional ?

No. :( The artifact declaration is a contract, something the downstream pipelines can depend on.

You can have a final task which creates dummy files, I suppose. But, that feels like cheating. If a downstream pipeline uses it, then it will need to validate that it is not a dummy file.

[Alexey Savchkov]

Can we come back to this point in 2024? Optional artifacts is a valid and natural case and are common in other CI systems. For example, when running tests I want to collect core dumps if they occur. Another example is a job which depending on its input parameters produces a varying number of artifacts (optional debug files, logs, reports or similar). The necessity to make dummy artifacts in all such cases only to satisfy GoCD internal logic is troublesome and disturbing. Could you please consider adding an "optional" attribute of the artifact element?

четверг, 25 июня 2015 г. в 20:10:09 UTC+6, Aravind SV:

[Chad Wilson]

It's a reasonable question. Possible different way of thinking about this:

When you have varying numbers of artifacts that are related to one another, put them in a directory together and artifact the whole directory as a single artifact (on the upload side). That way it is not dependent on any individual log, result etc. Either use scripting to collect them together post build (pre artifact) or change build scripting to ensure things all go into "one place".

If I recall correctly, you can still pull sub-paths of a given artifact in dependent pipelines rather than the "whole thing", in a way that the dependent job will fail if the artifact didn't include a given file/folder. (if I am wrong on this, this is not a great suggestion) This would allow to weaken some of the "contract" mentioned below?

-Chad

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/aa2762ac-18e9-4fff-a7bc-37a7a92be694n%40googlegroups.com.

[Alexey Savchkov]

Chad, thanks a lot for the quick and helpful response. Yes, currently to deal with optional artifacts I create "wrapping" folders and put them there (luckily GoCD can collect an empty artifact folder). It's just that while doing this yet again I thought that if the purpose of this was only to fool the system then the right way would probably be to modify the system in the first place to suit the real needs given that optional artifacts exist in other similar systems.

I realize that the development of GoCD is stopped but if this modification doesn't interfere much with the main code and can be made backward-compatible it would be a nice option to have in my opinion.

You received this message because you are subscribed to a topic in the Google Groups "go-cd" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/go-cd/EgUk3mrNebQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH8hmiS8%3DDidFVTqjAERs6-tG%3Dnmed_O5%2B5cuY%3DPzj0%2BpQ%40mail.gmail.com.