Good question - perhaps the behavior of "keep_input_artifact" is supposed 
to be exactly what I want which is:

* I want a "docker-tag" to run as the first post-processor step.  Then, I 
want the "docker-tag" step to pass an appropriate Docker artifact to the 
next step - "shell-local" (though, "shell-local" won't use that artifact 
for anything - just keep track of it for subsequent steps).
* I want "shell-local" to run a bash script which starts up a container 
based on the newly tagged image.  If the test fails, I want the Packer 
build to fail (this works great right now!).  If the test passes, I want 
the "shell-local" post-processor to pass the same artifact it was given to 
the next post-processor step - "docker-push" so that the now tested image 
will be pushed to ECR.

Now, perhaps "keep_input_artifact" is indeed passing along the appropriate 
artifact - in fact, when I look at the code for the "shell-local" post 
processor 
<https://github.com/hashicorp/packer/blob/master/post-processor/shell-local/post-processor.go>,
 
it looks like it _always_ passes along the input artifact.  Though, 
admittedly, I haven't familiarized myself with the rest of the code and I'm 
not proficient in the Go language.  But, it sure looks like it should work.

But, instead, what actually happens is that the "docker-push" step fails 
with "Can only import from docker-import and docker-tag artifacts".  If I 
remove the "shell-local" post-processing step from between "docker-tag" and 
"docker-push" (see original post for example), it works great - the 
appropriate image is pushed to ECR (though, obviously untested).

If I look at the "docker-push" post-processor code 
<https://github.com/hashicorp/packer/blob/master/post-processor/docker-push/post-processor.go>,
 
I believe I see the exact condition check that's leading to the error:

if artifact.BuilderId() != dockerimport.BuilderId &&
artifact.BuilderId() != dockertag.BuilderId {
err := fmt.Errorf(
"Unknown artifact type: %s\nCan only import from docker-import and 
docker-tag artifacts.",
artifact.BuilderId())
return nil, false, err
} 

My comment about the "passthrough_input_artifact" might be irrelevant - 
what I was trying to say was that I want it to work like I describe above - 
such that "shell-local" can be put between "docker-tag" and "docker-push" 
without breaking the build.  Does this make sense?

--
Nathan


On Tuesday, November 20, 2018 at 10:59:35 AM UTC-6, Megan Marsh wrote:
>
> I'm not sure what the difference between the "passthrough_input_artifact" 
> and "keep_input_artifact" behaviors would be. Can you elaborate?
>
> On Tue, Nov 20, 2018 at 8:57 AM Alvaro Miranda Aguilera <[email protected] 
> <javascript:>> wrote:
>
>> Hello.
>>
>> What is the exit code when the test fails ?
>>
>>
>>
>> On Tue, Nov 20, 2018 at 3:07 PM <[email protected] <javascript:>> wrote:
>>
>>> Thanks for the response!
>>>
>>> I did try that but the result was the same.  It occurs to me that a flag 
>>> like "passthrough_input_artifact" would be useful in this case.  I briefly 
>>> glanced at some of the post-processing code and it seems like it wouldn't 
>>> be too difficult to write a plugin (or, modify the existing shell-local 
>>> post-processor).  But, for now, I think I'll take the approach of running 
>>> the test(s) outside of the Packer build/tag/push phase.  I'd rather not 
>>> even push an image that doesn't pass the test(s) but it's not a hard 
>>> requirement.
>>>
>>> I certainly will continue to welcome ideas/suggestions. 
>>>
>>> Regards,
>>>
>>> Nathan
>>>
>>> On Monday, November 19, 2018 at 1:50:27 PM UTC-6, Megan Marsh wrote:
>>>>
>>>> You may be able to get the behavior you want by setting 
>>>> `keep_input_artifact` in your shell-local post-processor. 
>>>> https://www.packer.io/docs/templates/post-processors.html#input-artifacts
>>>>
>>>> On Mon, Nov 19, 2018 at 7:49 AM <[email protected]> wrote:
>>>>
>>>>> I'm trying to get Packer to build a Docker image, then run a container 
>>>>> from that image and execute a few tests against the running container 
>>>>> _before_ pushing the image back to a Docker registry.  I want to _only_ 
>>>>> push the image if tests pass.  Otherwise, I want the build to fail and 
>>>>> _not_ push anything.  
>>>>>
>>>>> I've tried putting a "shell-local" post-processing step in between the 
>>>>> "docker-tag" and the "docker-push" post-processing steps (pasted below).  
>>>>> The tests run as expected, but then the build fails on "docker-push" with 
>>>>> "Can only import from docker-import and docker-tag artifacts".  This 
>>>>> makes 
>>>>> sense I guess - I lose the Docker artifact once I run the shell-local 
>>>>> step 
>>>>> so it doesn't know what I'm asking it to push.  I've explored "manifest" 
>>>>> and "artifice" post-processors among other things but I haven't yet 
>>>>> figured 
>>>>> out how to make it work the way I want.
>>>>>
>>>>> Is what I'm trying to do possible with Packer?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> ...
>>>>>     "builders": [
>>>>>         {
>>>>>             "type": "docker",
>>>>>             "image": "{{user `base_image_repository`}}:latest",
>>>>>             "commit": true,
>>>>>             "ecr_login": true,
>>>>>             "login_server": "{{user `ecr_login_server`}}",
>>>>>             "changes": [
>>>>>                 "CMD /opt/app/run.sh"
>>>>>               ]
>>>>>         }
>>>>>     ],
>>>>>     "provisioners": [
>>>>>     ...
>>>>>     ],
>>>>>     "post-processors": [
>>>>>         [
>>>>>             {
>>>>>                 "type": "docker-tag",
>>>>>                 "repository": "{{user `docker_repository`}}",
>>>>>                 "tag": "{{user `version`}}"
>>>>>             },
>>>>>             {
>>>>>                 "type": "shell-local",
>>>>>                 "script": "./test-container.sh",
>>>>>                 "environment_vars": ["IMAGE_AND_TAG={{user 
>>>>> `docker_repository`}}:{{user `version`}}", "LEVEL={{user `level`}}"]
>>>>>             },
>>>>>             {
>>>>>                 "type": "docker-push",
>>>>>                 "ecr_login": true,
>>>>>                 "login_server": "{{user `ecr_login_server`}}"
>>>>>             }
>>>>>         ]
>>>>>     ]
>>>>> }
>>>>>
>>>>> -- 
>>>>> This mailing list is governed under the HashiCorp Community Guidelines 
>>>>> - https://www.hashicorp.com/community-guidelines.html. Behavior in 
>>>>> violation of those guidelines may result in your removal from this 
>>>>> mailing 
>>>>> list.
>>>>>  
>>>>> GitHub Issues: https://github.com/mitchellh/packer/issues
>>>>> IRC: #packer-tool on Freenode
>>>>> --- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Packer" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/packer-tool/08bec5d1-4c5e-4161-b0b6-cca6de9ae533%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/packer-tool/08bec5d1-4c5e-4161-b0b6-cca6de9ae533%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> -- 
>>> This mailing list is governed under the HashiCorp Community Guidelines - 
>>> https://www.hashicorp.com/community-guidelines.html. Behavior in 
>>> violation of those guidelines may result in your removal from this mailing 
>>> list.
>>>  
>>> GitHub Issues: https://github.com/mitchellh/packer/issues
>>> IRC: #packer-tool on Freenode
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Packer" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected] <javascript:>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/packer-tool/608e6d9d-c72f-492d-8630-18bbf93ed1d1%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/packer-tool/608e6d9d-c72f-492d-8630-18bbf93ed1d1%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Alvaro
>>
>> -- 
>> This mailing list is governed under the HashiCorp Community Guidelines - 
>> https://www.hashicorp.com/community-guidelines.html. Behavior in 
>> violation of those guidelines may result in your removal from this mailing 
>> list.
>>  
>> GitHub Issues: https://github.com/mitchellh/packer/issues
>> IRC: #packer-tool on Freenode
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Packer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/packer-tool/CAHqq0eyzOeHNtAMj2cjtbY6R5J6EKWhpA%3D%3DsoBUcogWQFgV%2Byg%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/packer-tool/CAHqq0eyzOeHNtAMj2cjtbY6R5J6EKWhpA%3D%3DsoBUcogWQFgV%2Byg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
This mailing list is governed under the HashiCorp Community Guidelines - 
https://www.hashicorp.com/community-guidelines.html. Behavior in violation of 
those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
--- 
You received this message because you are subscribed to the Google Groups 
"Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/packer-tool/6305906d-6c3f-4b8f-aa19-652b7ceead02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to