Re: [configuration-as-code] Descriptors configuration

[nicolas de loof]

Thanks !

2017-11-27 23:53 GMT+01:00 Jesse Glick :

> On Fri, Nov 24, 2017 at 8:17 AM, nicolas de loof
>  wrote:
> > I'm looking if stapler can
> > easily answer "does this descriptor have a global view" without making
> > assumption on the view template language
>
> Try `Descriptor.getGlobalConfigPage`.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr2G8BuOuprwSpnSgT8uOof_
> KaWbW7m-P0C8ETHTa61afA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznxhBahay1WnKM2Oc_VmM8TzaR%2BnapFXZ-%2Bs9fmnniYZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Kohsuke Kawaguchi]

Thanks for driving this.

If this change inadvertently remove somebody's commit access, presumably we
expect people to follow this

and
mail this list?

On Mon, Nov 27, 2017 at 4:25 PM Daniel Beck  wrote:

> Hi everyone,
>
> For a long time, we didn't really manage GitHub permissions for plugins:
> We just added new repos and contributors to the 'Everyone' team, giving
> everyone access to everything, and that was it. Contrary to its name, it
> doesn't actually include _everyone_, at least not anymore: We've moved away
> from adding people to the Everyone team over a year ago. But it still has
> hundreds of members, and provides write access to more than 1200
> repositories.
>
> While contributors are mostly well-behaved, we've occasionally seen PRs
> merged by people who weren't regular contributors to those plugins,
> resulting in conflict with actual maintainers. Since these users cannot
> release the plugins anyway, the benefit of being able to do this is
> questionable at best. Not to mention the problem of malicious or accidental
> data loss through people force-pushing into Git (this, accidentally, has
> happened with dozens -- hundreds? -- of repositories back in 2015, and
> caused a considerable mess).
>
> I know that quite a few plugin maintainers have long removed the Everyone
> team from their plugin repositories to prevent such problems, but the
> default is still to add the team to a new plugin repo.
>
> Given the size of the Jenkins project, this is untenable. I plan to remove
> the Everyone team from all repositories, instead granting direct access to
> contributors who previously got their write access from the Everyone team.
> This way, we should be able to retain access for those who legitimately
> have it, while removing those who have no relationship to any particular
> plugin.
>
> Right now, I plan to grant direct write access to a plugin to users who:
>
> 1. Have write access to a repository through the Everyone team only
> 2. Are considered 'contributors' by GitHub (meaning they have commits
> associated with them in the repo)
> 3. Have at least 5 'contributions' (~commits in the contributors graph)
>
> The first two should be obvious (with the caveat that badly set up GH
> accounts -- their commits not associated with the account -- will lose
> access). The third is where it gets tricky: Not everyone who contributed to
> a repository, and currently has write access to it via 'Everyone' team,
> should legitimately have write access to it in the future. Unfortunately,
> GitHub makes it impossible to efficiently determine who has performed
> various maintainer-specific actions, such as created a release tag, or
> merged a pull request -- and these might still miss legitimate
> co-maintainers who just don't have direct access.
>
> So I will instead use a minimum number (currently 5) of contributions
> required for someone to retain access. Once we've drastically limited who
> has access to any given repo, we can always fine-tune this later. There
> will also be a log of what changed so this can be referenced later in case
> of questions related to lost permissions.
>
> While this may be a painful change if the above rules get the needed
> permissions wrong, it's an important one, and I'm trying to make it as
> smooth as possible. Please bring up your concerns and questions in this
> thread and I'll do my best to address them.
>
> I don't think this is JEPable, as this doesn't actually create a
> longer-running process, it's just a one-time legacy permission migration.
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xLdArgFQDYw0weXhZpmzgdzGs0sDvKG%2Ba9xy%3DeTD7-9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Mark Waite]

That sounds reasonable to me.

I won't remove "Everyone" from the git-client-plugin or the git-plugin
until after you've made the change, since removing that group would remove
write permission for key people (Stephen, Jesse, Sam, Liam, etc.).

I don't seem to be able to add people to either the
git-client-plugin-developers group or to the git-plugin-developers group.
Is that expected?

Mark Waite

On Mon, Nov 27, 2017 at 6:18 PM Richard Bywater  wrote:

> Great - thanks for your help Daniel!
>
> Richard.
>
> On Tue, 28 Nov 2017 at 14:13 Daniel Beck  wrote:
>
>>
>> > On 28. Nov 2017, at 01:39, Richard Bywater  wrote:
>> >
>> > Should a plugin maintainer have full admin access to the repo? Reason I
>> ask is that I recently took over as maintainer for the HTML publisher
>> plugin but don't have any access outside of committing etc. As the
>> maintainer should I have slightly more access?
>>
>> Sooo… fun fact: You only have write access to that repo because you're in
>> Everyone. Good news: With 18 contributions, you'd get direct access in this
>> process ;-)
>>
>> Added you to the dedicated per-repo team, and granted Admin access. For a
>> while I used to reduce the access level of the 'foo-plugin Developers' team
>> manually from Admin to Write, the reason being the "Danger Zone" options
>> usually available to repo admins (transfer/delete/… repo). Those can now be
>> disabled for repo admins org-wide, so we routinely grant Admin access to
>> maintainers again.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/11E33829-614A-4979-A037-AE5CDD899367%40beckweb.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMui946Wsi6_f6H64Y9YFKO3t_H%3D50ZL-LnFzVyyuzjx8zwPNQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtF2SU14VEuAZ1bEonOSduAigdth4bNAsqMiNmw4shLO5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Richard Bywater]

Great - thanks for your help Daniel!

Richard.

On Tue, 28 Nov 2017 at 14:13 Daniel Beck  wrote:

>
> > On 28. Nov 2017, at 01:39, Richard Bywater  wrote:
> >
> > Should a plugin maintainer have full admin access to the repo? Reason I
> ask is that I recently took over as maintainer for the HTML publisher
> plugin but don't have any access outside of committing etc. As the
> maintainer should I have slightly more access?
>
> Sooo… fun fact: You only have write access to that repo because you're in
> Everyone. Good news: With 18 contributions, you'd get direct access in this
> process ;-)
>
> Added you to the dedicated per-repo team, and granted Admin access. For a
> while I used to reduce the access level of the 'foo-plugin Developers' team
> manually from Admin to Write, the reason being the "Danger Zone" options
> usually available to repo admins (transfer/delete/… repo). Those can now be
> disabled for repo admins org-wide, so we routinely grant Admin access to
> maintainers again.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/11E33829-614A-4979-A037-AE5CDD899367%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMui946Wsi6_f6H64Y9YFKO3t_H%3D50ZL-LnFzVyyuzjx8zwPNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Daniel Beck]

> On 28. Nov 2017, at 01:39, Richard Bywater  wrote:
> 
> Should a plugin maintainer have full admin access to the repo? Reason I ask 
> is that I recently took over as maintainer for the HTML publisher plugin but 
> don't have any access outside of committing etc. As the maintainer should I 
> have slightly more access?

Sooo… fun fact: You only have write access to that repo because you're in 
Everyone. Good news: With 18 contributions, you'd get direct access in this 
process ;-)

Added you to the dedicated per-repo team, and granted Admin access. For a while 
I used to reduce the access level of the 'foo-plugin Developers' team manually 
from Admin to Write, the reason being the "Danger Zone" options usually 
available to repo admins (transfer/delete/… repo). Those can now be disabled 
for repo admins org-wide, so we routinely grant Admin access to maintainers 
again.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/11E33829-614A-4979-A037-AE5CDD899367%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] Change core logging from Java Utils Logging

[Stephen Connolly]

On Mon 27 Nov 2017 at 22:51, Jesse Glick  wrote:

> On Wed, Nov 22, 2017 at 2:07 PM, Stephen Connolly
>  wrote:
> > there is the logging of incorrect values
>
> I guess this is a concern according to the handler.
> `Logger.log(LogRecord)` calls `Handler.publish` synchronously. And
> typical handlers would then format the message synchronously if they
> log it at all. In Jenkins, the problematic handler is
> `RingBufferLogHandler`, which formats messages asynchronously, or
> rather allows callers such as `Functions.printLogRecordHtml` to do so.
> It could instead call `setMessage` synchronously with the result of
> `SimpleFormatter.formatMessage` (and then call `setParameters(null)`
> to clean up). This would actually have another benefit, even if no one
> ever abused the lambda form: avoiding nasty memory leaks, which I have
> personally encountered.


Or any other user provided handler could have the same issue.

Much better if we just switch to a decent logging framework and be done

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Wxxy5RUatk4E8b80tvPydHUCGP2B-BraFH3ehR-V2Lg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyUj-D0_YN34xYUBcR37R%3D1O9tnpmth-DYmM3-25qZBXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Richard Bywater]

That sounds like a reasonable approach to me.

Semi related question re "I know that quite a few plugin maintainers have
long removed the Everyone team from their plugin repositories to prevent
such problems, but the default is still to add the team to a new plugin
repo."

Should a plugin maintainer have full admin access to the repo? Reason I ask
is that I recently took over as maintainer for the HTML publisher plugin
but don't have any access outside of committing etc. As the maintainer
should I have slightly more access?

Thanks
Richard.

On Tue, 28 Nov 2017 at 13:25 Daniel Beck  wrote:

> Hi everyone,
>
> For a long time, we didn't really manage GitHub permissions for plugins:
> We just added new repos and contributors to the 'Everyone' team, giving
> everyone access to everything, and that was it. Contrary to its name, it
> doesn't actually include _everyone_, at least not anymore: We've moved away
> from adding people to the Everyone team over a year ago. But it still has
> hundreds of members, and provides write access to more than 1200
> repositories.
>
> While contributors are mostly well-behaved, we've occasionally seen PRs
> merged by people who weren't regular contributors to those plugins,
> resulting in conflict with actual maintainers. Since these users cannot
> release the plugins anyway, the benefit of being able to do this is
> questionable at best. Not to mention the problem of malicious or accidental
> data loss through people force-pushing into Git (this, accidentally, has
> happened with dozens -- hundreds? -- of repositories back in 2015, and
> caused a considerable mess).
>
> I know that quite a few plugin maintainers have long removed the Everyone
> team from their plugin repositories to prevent such problems, but the
> default is still to add the team to a new plugin repo.
>
> Given the size of the Jenkins project, this is untenable. I plan to remove
> the Everyone team from all repositories, instead granting direct access to
> contributors who previously got their write access from the Everyone team.
> This way, we should be able to retain access for those who legitimately
> have it, while removing those who have no relationship to any particular
> plugin.
>
> Right now, I plan to grant direct write access to a plugin to users who:
>
> 1. Have write access to a repository through the Everyone team only
> 2. Are considered 'contributors' by GitHub (meaning they have commits
> associated with them in the repo)
> 3. Have at least 5 'contributions' (~commits in the contributors graph)
>
> The first two should be obvious (with the caveat that badly set up GH
> accounts -- their commits not associated with the account -- will lose
> access). The third is where it gets tricky: Not everyone who contributed to
> a repository, and currently has write access to it via 'Everyone' team,
> should legitimately have write access to it in the future. Unfortunately,
> GitHub makes it impossible to efficiently determine who has performed
> various maintainer-specific actions, such as created a release tag, or
> merged a pull request -- and these might still miss legitimate
> co-maintainers who just don't have direct access.
>
> So I will instead use a minimum number (currently 5) of contributions
> required for someone to retain access. Once we've drastically limited who
> has access to any given repo, we can always fine-tune this later. There
> will also be a log of what changed so this can be referenced later in case
> of questions related to lost permissions.
>
> While this may be a painful change if the above rules get the needed
> permissions wrong, it's an important one, and I'm trying to make it as
> smooth as possible. Please bring up your concerns and questions in this
> thread and I'll do my best to address them.
>
> I don't think this is JEPable, as this doesn't actually create a
> longer-running process, it's just a one-time legacy permission migration.
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMui9466JbUq2SOrYdLR9Bu-08W4wGzh%2BG_qATcJR3xc3EUk1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Removing the Everyone team in the jenkinsci GitHub org

[Daniel Beck]

Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We 
just added new repos and contributors to the 'Everyone' team, giving everyone 
access to everything, and that was it. Contrary to its name, it doesn't 
actually include _everyone_, at least not anymore: We've moved away from adding 
people to the Everyone team over a year ago. But it still has hundreds of 
members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged 
by people who weren't regular contributors to those plugins, resulting in 
conflict with actual maintainers. Since these users cannot release the plugins 
anyway, the benefit of being able to do this is questionable at best. Not to 
mention the problem of malicious or accidental data loss through people 
force-pushing into Git (this, accidentally, has happened with dozens -- 
hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team 
from their plugin repositories to prevent such problems, but the default is 
still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the 
Everyone team from all repositories, instead granting direct access to 
contributors who previously got their write access from the Everyone team. This 
way, we should be able to retain access for those who legitimately have it, 
while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits 
associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts 
-- their commits not associated with the account -- will lose access). The 
third is where it gets tricky: Not everyone who contributed to a repository, 
and currently has write access to it via 'Everyone' team, should legitimately 
have write access to it in the future. Unfortunately, GitHub makes it 
impossible to efficiently determine who has performed various 
maintainer-specific actions, such as created a release tag, or merged a pull 
request -- and these might still miss legitimate co-maintainers who just don't 
have direct access.

So I will instead use a minimum number (currently 5) of contributions required 
for someone to retain access. Once we've drastically limited who has access to 
any given repo, we can always fine-tune this later. There will also be a log of 
what changed so this can be referenced later in case of questions related to 
lost permissions.

While this may be a painful change if the above rules get the needed 
permissions wrong, it's an important one, and I'm trying to make it as smooth 
as possible. Please bring up your concerns and questions in this thread and 
I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running 
process, it's just a one-time legacy permission migration.

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: [configuration-as-code] Descriptors configuration

[Jesse Glick]

On Fri, Nov 24, 2017 at 8:17 AM, nicolas de loof
 wrote:
> I'm looking if stapler can
> easily answer "does this descriptor have a global view" without making
> assumption on the view template language

Try `Descriptor.getGlobalConfigPage`.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2G8BuOuprwSpnSgT8uOof_KaWbW7m-P0C8ETHTa61afA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] Change core logging from Java Utils Logging

[Jesse Glick]

On Wed, Nov 22, 2017 at 2:07 PM, Stephen Connolly
 wrote:
> there is the logging of incorrect values

I guess this is a concern according to the handler.
`Logger.log(LogRecord)` calls `Handler.publish` synchronously. And
typical handlers would then format the message synchronously if they
log it at all. In Jenkins, the problematic handler is
`RingBufferLogHandler`, which formats messages asynchronously, or
rather allows callers such as `Functions.printLogRecordHtml` to do so.
It could instead call `setMessage` synchronously with the result of
`SimpleFormatter.formatMessage` (and then call `setParameters(null)`
to clean up). This would actually have another benefit, even if no one
ever abused the lambda form: avoiding nasty memory leaks, which I have
personally encountered.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Wxxy5RUatk4E8b80tvPydHUCGP2B-BraFH3ehR-V2Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Docker agent build script wrapper

[Oleksandr Rudak]

Hi,

We are building scientific model running and testing environment product. 
We use Jenkins as a core building, integration and model running tool. Now 
our users are scientist and have little technological background so we look 
to fold our current Jenkinsfile into something more compact and 
transparent. We've tried few things. SimpleBuildStep, which is too basic to 
handle agent/docker stuff. Step is too complicated as it involved 
distributed execution parallelism. Also we tried 'load' to load Jenkinsfile 
generated in the working directory. All ways have pros/cons but none 
provides in full what we try to accomplish.

Any ideas how to do such wrapping? I think about custom `agent` which would 
provide docker context and will imply the rest of the configuration and 
hide it from user. Possibly some workflow extension or something like this. 
Any thoughts are welcome.

Below is the anticipated Jenkinsfile how it would ideally look. Attached is 
the original Jenkins with detailed steps we want to cloak from user.

node {
stage ('setup') {
setupEnv (dockerImage:'dockerImage123')
}
stage ('train') {
runNotebook (notebookPath:'notebookPath212')
// { prepare, run, archive, legion }
// runNotebook (notebookPath:'notebookPath213')
}
stage ('deploy') {
deployModel ()
}
stage ('test') {
testModel ()
}
}



Thanks
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/5a2441d6-72ef-45f7-a415-356510c8a9cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
pipeline {
agent { 
docker {
image 'drun.kharlamov.biz/drun/base-python-image:latest'
args '-v drun:/drun -u 0:0 --network=drun_drun_root -e 
"DOCKER_TLS_VERIFY=1" -e "DOCKER_HOST=${DOCKER_HOST}" -e 
"DOCKER_CERT_PATH=${DOCKER_CERT_PATH}" -e 
"MODEL_SERVER_URL=${DRUN_MODEL_SERVER_URL}"'
}
}
stages {
stage('clone'){
steps {
sh '''
pip install -i https://drun.kharlamov.biz/pypi/ 
drun
'''
}
}
stage('run notebook'){
steps {
sh '''
jupyter nbconvert --execute 
"Digit-Recognition/Recognizing digits.ipynb"
cp "Digit-Recognition/Recognizing digits.html" 
notebook.html
mkdir -p release-models
cp -rf /drun/* release-models/
'''
}
}
stage('archive notebook artifacts'){
steps {
archiveArtifacts 
'release-models/image_recognize.model'
archiveArtifacts 'Digit-Recognition/*.html'
archiveArtifacts 'notebook.html'
}
}
stage('deploy to legion'){
steps {
sh '''
legion build 
release-models/image_recognize.model
legion deploy --model-id recognize_digits
'''
sleep time: 20, unit: 'SECONDS'
}
}
stage('run tests'){
steps {
sh '''
cd "Digit-Recognition/tests"
nosetests --with-xunit
'''
junit 'Digit-Recognition/tests/nosetests.xml'
}
}
}
}