5:41 p.m.
On Tue, Feb 19, 2019 at 7:23 PM Barak Korren <bkorren(a)redhat.com> wrote:
> 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 <ederevea(a)redhat.com> 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
<https://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_stand... 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.
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Tue, 19 Feb 2019 at 09:14, Joey Ma <majunjiev(a)gmail.com> wrote:
> Hi all,
Hi Joey,
*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`.
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.*
Not sure if make myself clear. Your comments and suggestions are very
welcome. Thanks in advance.
Regards,
Joey
[1]:
https://github.com/oVirt/ovirt-engine-sdk-go/blob/master/.travis/deploy-c...
[2]:
https://github.com/oVirt/ovirt-engine-sdk/blob/master/automation/deploy-o...
[3]:
https://github.com/kubevirt/kubevirt/blob/master/hack/gen-client-python/d...
[4]:
https://ovirt-infra-docs.readthedocs.io/en/latest/CI/Writing_STDCI_secret...
> Regards,
> Barak.