Pubsub in ci

[bretambrose]

• Run pub sub node sample with both direct mqtt and websocket configurations in CI

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[TingDaoK]

Why not use github actions to run the samples as well? Feel like if we can add tests steps to builder.json. We can store the credentials in github secrets as what we did for other repos? In this way we can test it across platform?

[bretambrose]

Why not use github actions to run the samples as well? Feel like if we can add tests steps to builder.json. We can store the credentials in github secrets as what we did for other repos? In this way we can test it across platform?

We can't use internal VPC infrastructure then: no proxies, no event stream servers, no gg cores

[TingDaoK]

Why not use github actions to run the samples as well? Feel like if we can add tests steps to builder.json. We can store the credentials in github secrets as what we did for other repos? In this way we can test it across platform?

We can't use internal VPC infrastructure then: no proxies, no event stream servers, no gg cores

Do we need proxies and gg cores for pubsub sample?

[bretambrose]

Why not use github actions to run the samples as well? Feel like if we can add tests steps to builder.json. We can store the credentials in github secrets as what we did for other repos? In this way we can test it across platform?

We can't use internal VPC infrastructure then: no proxies, no event stream servers, no gg cores

Do we need proxies and gg cores for pubsub sample?

Atm? no. Eventually? yes.

[TingDaoK]

yeah, just feel like if we can have at least one sample (pubsub that only needs the credentials to run) runs across platform, we can be more confident. For the other samples, we need the internal environment for sure. Anyway, this is good! We finally have our samples tested!🙆‍♂️

[bretambrose]

yeah, just feel like if we can have at least one sample (pubsub that only needs the credentials to run) runs across platform, we can be more confident. For the other samples, we need the internal environment for sure. Anyway, this is good! We finally have our samples tested!ok_man

I think what you're thinking of here is a separate {OS x Architecture} test set that would verify/validate that all of the expected, embedded native libraries are present and invoked properly. We could definitely do that with containers/builder but probably limit it to just successfully creating a single native resource (elg, for example). Ideally, we should do it as a RC test step in CD pipelines as well. I'm going to add both of these ideas to the IoT Quality doc.

The SDKs themselves are platform/arch agnostic, so if you screw up something at that level, we don't want to find it out when running CI on the SDKs, instead we want to find out earlier in either the native library (io/cal/common) or the appropriate CRT.