בתאריך יום ו׳, 22 בפבר׳ 2019, 6:13, מאת Joey Ma ‏<majunjiev@gmail.com>:


On Wed, Feb 20, 2019 at 12:41 AM Joey Ma <majunjiev@gmail.com> wrote:


On Tue, Feb 19, 2019 at 7:23 PM Barak Korren <bkorren@redhat.com> wrote:


On Tue, 19 Feb 2019 at 09:14, Joey Ma <majunjiev@gmail.com> wrote:
Hi all,

Hi Joey,
 

With the generous help of several nice guys, currently the Go SDK related projects, oVirt/ovirt-engine-sdk-go and oVirt/go-ovirt, are already available under oVirt org, and the integration of oVirt/ovirt-engine-sdk-go with oVirt STD-CI is also completed [1]. Sincerely thank you to everyone.

While there is still an issue left that we need a proper solution to integrate oVirt/ovirt-engine-sdk-go with TravisCI which could push the auto-generated codes into oVirt/go-ovirt. Previously I adopted my personal github access token which is stored encrypted [2] to work it out. 

But as it's been under oVirt community, we need a more regular way to make this. As @Evgheni suggested, maybe a new access token from a dedicated github account or via the Jenkins job will work?

Any one could help? Any insights into this would be appreciated and thanks in advance.
If you do it from the STDCI script (The Jenkin job), we could make the credentials for the STDCI GitHub bot available to the script when it runs (See the section about secrets in the standard CI docs for a full explanation about how this works).
 
I`d want do understand how the flow works and what is its purpose, it sounds to me a bit strange that we need to push from one repo to the other.

Hi Barak,

Basically the root cause is that the Go SDK codes are automatically generated by oVirt/ovirt-engine-sdk-go, but reside in oVirt/go-ovirt.

Current workflow is:
1. Once a pull request get merged in ovirt-engine-sdk-go, TravisCI will run the build phrase, which mainly generates the Go SDK codes;
2. If the build phrase has passed,  TravisCI will then trigger the script deploy-codes.sh [1];
3. The deploy-codes.sh [1]  pushes the auto-generated Go SDK codes to go-ovirt via the preconfigured credential of github account;
4. Eventually users are able to utilize the latest SDK by using "github.com/ovirt/go-ovirt" as the import path;

The reasons for this are:
1. The auto-generated codes are better to be put into a dedicated repo, not in its generator repo;
2. The dedicated go-ovirt repo provides a convenient way for users to utilized the SDK package, which is also the common way to import Go packages;

From my perspective, there are two projects with similar purpose:
* oVirt/ovirt-engine-sdk: TravisCI will trigger a script [2] to push newly generated docs into its gh-pages branch once new commits merged.
> This feature will also get implemented in oVirt/ovirt-engine-sdk-go ASAP.
* kubevirt/kubevirt: After new commits merged, the kubevirt repo would trigger the script [3] to deploy new auto-generated Python client codes into kubevirt/client-python. This enables users could easily install the Python client by running `pip install git+https://github.com/kubevirt/client-python.git`.

Hi Barak,

I was wondering if I made this clear.
 
Regarding to the credentials, the environment variables binding secrets mentioned in STD-CI doc are effective solutions and definitely I would like to prefer the common rules used in community. 
> Also I've a question that make me confused for a long time, are the two environment variables `encrypted_1fc90f464345_key` and `encrypted_1fc90f464345_iv` used in [2] defined in a STDCI secrets file [4] for oVirt/ovirt-engine-sdk? For I could not find where they are defined.

This definitely was a stupid question. I apologize for not carefully reading [1] which could tell the answers.  

[1] and [2]probably provide us another way to work it out via deploy-key. Please let me introduce the working steps:
1. Generate a pair of public and private keys;
2. Upload the public key to oVirt/go-ovirt as a deploy-key as mentioned in [2];
3. Follow [1] to encrypt the private key and add the encrypted one into the oVirt/ovirt-engine-sdk-go repo;
4. In the deploy script [3] of oVirt/ovirt-engine-sdk-go, add the logic codes of decrypting and ssh-adding the private key;
Then the script could be able to access and push the codes in oVirt/go-ovirt.

This seems less risky than the previous solution which using github account token. I guess it's the solution also adapted by oVirt/ovirt-engine-sdk [4] and oVirt/ovirt-engine-api-model [5].

So, Barak, may I have your clarification on if my proposal could comply with the regular rules? If yes, I'd proceed with the next step. Thanks in advance.

Hi Joey,

I apologise for not answering sooner, moving kubevirt out of oVirt`s Jenkins instance and into it's own had kept us busy the last few days.

The are no strict rules you need to follow, we (oVirt's infra team) provide services that developers can choose to use or not to.

Some things, like being included in the oVirt official releases, require using certain services, but other then that you are free to do as you please.

When it comes to stuff that runs in Travis, we don't maintain any if that, so I can't really comment about how things are done there.

If you want to use the services we provide I'd be happy to help.

Regards,
Barak.


Regards,
Joey