using the juju client from jenkins

[James Beedy]

I've a feeling that the majority of the CI/CD I've left in my trails that
attaches a resource from jenkins via juju bash cli are probably not
working. The latest CI/CD I've setup runs `juju attach` from jenkins, and I
have to login to the jenkins shell and su to the jenkins user and login to
be able to run my deploy step in jenkins.

Is there a way that people are doing the jenkins<->juju dance without
lib-juju?

[Konstantinos Tsakalozos]

Hi James,

We build our charms, push them to the store on the edge channel, and
then our tests run against what is on edge. With this approach the
team can sync on a specific build revision instead of each one
separately trying to rebuild the charm locally and reproduce any
unexpected behaviour. As soon as we are happy with a build we just
promote it to the next channel (beta,candidate or stable). You can
find our work here:
https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms

Cheers,
Konstantinos

Post by James Beedy
I've a feeling that the majority of the CI/CD I've left in my trails that
attaches a resource from jenkins via juju bash cli are probably not working.
The latest CI/CD I've setup runs `juju attach` from jenkins, and I have to
login to the jenkins shell and su to the jenkins user and login to be able
to run my deploy step in jenkins.
Is there a way that people are doing the jenkins<->juju dance without
lib-juju?
--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju

[James Beedy]

Konstantinos,

Thanks for that. I need to get CI/CD setup for my charms, that will be very
helpful to me very soon.

Possibly I didn't illuminate the issue I'm having correctly though.

1) I have a pdl-api charm, that manages the pdl-api.snap.
2) My CI/CD pipeline for the pdl-api has two steps; build, deploy.
- The build job tests the code and builds the snap, then passes the
built artifact to the deploy step.
- The deploy step basically takes the built snap and attaches it to the
pdl-api charm https://imgur.com/a/UiIg7

The issue at hand, is that my jenkins user token expires and I end up with
a failing deploy job http://paste.ubuntu.com/26019762/ .

To remedy this, I always have to `juju ssh jenkins/0; sudo -ui jenkins;
juju login`

Is this more clear?

Thanks






On Wed, Nov 22, 2017 at 2:17 AM, Konstantinos Tsakalozos <

Post by Konstantinos Tsakalozos
Hi James,
We build our charms, push them to the store on the edge channel, and
then our tests run against what is on edge. With this approach the
team can sync on a specific build revision instead of each one
separately trying to rebuild the charm locally and reproduce any
unexpected behaviour. As soon as we are happy with a build we just
promote it to the next channel (beta,candidate or stable). You can
https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms
Cheers,
Konstantinos

Post by James Beedy
I've a feeling that the majority of the CI/CD I've left in my trails that
attaches a resource from jenkins via juju bash cli are probably not

working.

Post by James Beedy
The latest CI/CD I've setup runs `juju attach` from jenkins, and I have

to

Post by James Beedy
login to the jenkins shell and su to the jenkins user and login to be

able

Post by James Beedy
to run my deploy step in jenkins.
Is there a way that people are doing the jenkins<->juju dance without
lib-juju?
--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju

[Tom Barber]

I'm not sure if this is of any use:

https://github.com/spiculedata/circleci-juju/blob/master/charmlogin

I use `expect` to process a charm login for me.

Post by James Beedy
Konstantinos,
Thanks for that. I need to get CI/CD setup for my charms, that will be
very helpful to me very soon.
Possibly I didn't illuminate the issue I'm having correctly though.
1) I have a pdl-api charm, that manages the pdl-api.snap.
2) My CI/CD pipeline for the pdl-api has two steps; build, deploy.
    - The build job tests the code and builds the snap, then passes
the built artifact to the deploy step.
    - The deploy step basically takes the built snap and attaches it
to the pdl-api charm https://imgur.com/a/UiIg7
The issue at hand, is that my jenkins user token expires and I end up
with a failing deploy job http://paste.ubuntu.com/26019762/ .
To remedy this, I always have to `juju ssh jenkins/0; sudo -ui
jenkins; juju login`
Is this more clear?
Thanks
On Wed, Nov 22, 2017 at 2:17 AM, Konstantinos Tsakalozos
Hi James,
We build our charms, push them to the store on the edge channel, and
then our tests run against what is on edge. With this approach the
team can sync on a specific build revision instead of each one
separately trying to rebuild the charm locally and reproduce any
unexpected behaviour. As soon as we are happy with a build we just
promote it to the next channel (beta,candidate or stable). You can
https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms
<https://github.com/juju-solutions/kubernetes-jenkins/tree/master/charms>
Cheers,
Konstantinos

Post by James Beedy
I've a feeling that the majority of the CI/CD I've left in my

trails that

Post by James Beedy
attaches a resource from jenkins via juju bash cli are probably

not working.

Post by James Beedy
The latest CI/CD I've setup runs `juju attach` from jenkins, and

I have to

Post by James Beedy
login to the jenkins shell and su to the jenkins user and login

to be able

Post by James Beedy
to run my deploy step in jenkins.
Is there a way that people are doing the jenkins<->juju dance

without

Post by James Beedy
lib-juju?
--
Juju mailing list
https://lists.ubuntu.com/mailman/listinfo/juju

<https://lists.ubuntu.com/mailman/listinfo/juju>

--
Spicule Limited is registered in England & Wales. Company Number: 09954122.
Registered office: First Floor, Telecom House, 125-135 Preston Road,
Brighton, England, BN1 6AF. VAT No. 251478891.


All engagements are subject to Spicule Terms and Conditions of Business.
This email and its contents are intended solely for the individual to whom
it is addressed and may contain information that is confidential,
privileged or otherwise protected from disclosure, distributing or copying.
Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Spicule Limited. The
company accepts no liability for any damage caused by any virus transmitted
by this email. If you have received this message in error, please notify us
immediately by reply email before deleting it from your system. Service of
legal notice cannot be effected on Spicule Limited by email.