[JENKINS-47113] Populate the authorities after a successful authentication to Github #87

Wadeck · 2017-11-01T09:33:48Z

~~when the user logged in using Github login, we trigger the loggedIn event in order to populate the LastGrantedAuthorities~~
also when he just uses the Github token, we trigger the authenticated event (but not the loggedIn)
store the access token when the user authenticated by Github token or login to populate the future calls using API Token.
add an embedded Jetty server in the test to check the behavior when talking with GitHub.

See JENKINS-47113.

Proposed changelog entries

After a successful login using GitHub login page, the security groups are populated when using CLI

Submitter checklist

JIRA issue is well described
Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
* Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
Appropriate autotests or explanation to why this change has no tests
For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@reviewbybees @daniel-beck

- add failing test to reproduce the case - after using the github auth, we retrieve the groups normally but for next auth with ApiToken, we do not receive the groups

- add fireLoggedIn after GithubAuth - add fireAuthenticated after GithubToken

ghost · 2017-11-01T09:34:19Z

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

dwnusbaum · 2017-11-01T17:59:40Z

src/test/java/org/jenkinsci/plugins/Jenkins47113.java

+//
+//        wc = j.createWebClient();
+//        // in case of GithubToken there is no session so we retrieve the same result
+//        makeRequestWithAuthCodeAndVerify(encodeBasic(aliceLogin, aliceApiRestToken), "alice", Arrays.asList("authenticated", "org-a", "org-a*team-b"));


Should the commented out code be deleted? It looks like that code is in testBob_usingGithubLogin.

It's not the same. In such case the commented code is related to the TODO in the use of GitHub token that should or should not trigger the loggedIn event.

Ah ok that makes sense.

dwnusbaum · 2017-11-01T18:16:45Z

src/test/java/org/jenkinsci/plugins/Jenkins47113.java

+
+    @Issue("JENKINS-47113")
+    @Test
+    public void testGroupPopulation() throws Exception {


I'd consider moving this stuff to an @Before method and adding @Test to testAlice_usingGithubToken and testBob_usingGithubLogin, and maybe renaming those methods to testLoginUsingGithubApiToken and testLoginUsingGithubOauth?

For that point I followed some previous comments from Jesse, telling me it's better to have a single test in order to avoid double Jenkins startup.
But in this plugin, there's not a lot of tests, so you're right I think, will do the change 👍

dwnusbaum · 2017-11-01T18:41:57Z

src/main/java/org/jenkinsci/plugins/GithubSecurityRealm.java

+                        SecurityListener.fireAuthenticated(new GithubOAuthUserDetails(token.getName(), github.getAuthorities()));
+
+                        //TODO do we want to trigger a loggedIn event when using GitHub token ?
+                        // SecurityListener.fireLoggedIn(token.getName());


SecurityListener#loggedIn JavaDoc says:

Fired when a user has logged in via the web UI.

So the question is whether this code is called from the UI, right? I'll do some local testing, would be good to decide either way and remove the TODO before merging.

In the use of GitHub login, it's when we use the process showing you the GitHub login page etc. It's the case of "Web UI" authentication.
But in the case of GitHub token, we are in the same case as for the API Token in core, it's not trough Web UI but by REST calls, hence my TODO.

FTR I proposed changes in the JavaDoc of loggedIn in #3074 from "via the web UI" to "notion of cache / storage of authentication"

Ok, thanks for the link to the proposed JavaDoc changes. I looked through other SecurityRealm implementations (listed here), but didn't find any that called loggedIn for a token-based authentication. The main reason to call fireLoggedIn would be to populate the last granted authorities, right?

Essentially yes, but as you mentionned it's not a behavior that is really desired. I will remove the comments 👍

- add a TODO on the GithubAPITest that use Ignore but should use Assume

samrocketman · 2017-11-03T23:32:09Z

What happens to the granted authorities when a user's access is revoked from an organization or team but they don't log in through the web UI?

…just using Github token

daniel-beck · 2017-11-06T10:45:02Z

What happens to the granted authorities when a user's access is revoked from an organization or team but they don't log in through the web UI?

This is acting as a cache, so previous access remains. The user record in Jenkins can be deleted, this will remove the associations (even if the user might reappear due to e.g. occurring in SCM).

samrocketman · 2017-11-07T02:25:55Z

The user record in Jenkins can be deleted, this will remove the associations (even if the user might reappear due to e.g. occurring in SCM).

Are you referring to User.get('username').delete() when you say delete the user record? In general, I know there's large organizations which use this OAuth as a form of authorization. I don't think it would be good behavior if a user is granted authorizations after they've been revoked.

Think of the following scenario from an organization using GitHub Enterprise:

A user is revoked from a team or organization but they still require access to other organizations and teams in Jenkins.

I do not think this change will be accepted if it doesn't properly match the user's state of access with GitHub.

Idea: Why not store the GitHub API token generated from a user login during the OAuth process with the user record? This could then be used to determine authorizations and even take advantage of the caches provided for GitHub organizations and teams in the plugin. When the Jenkins API token is used; it could use the cached authorization token from the user login to query GitHub directly for organizations and teams.

Wadeck · 2017-11-07T07:05:09Z

The case you mentionned currently did not work either. With current version if you use Github Token or Login you will have the correct authorization but with Jenkins API Token, you will simply be authenticated.

Idea: Why not store the GitHub API token generated from a user login during the OAuth process with the user record? This could then be used to determine authorizations and even take advantage of the caches provided for GitHub organizations and teams in the plugin. When the Jenkins API token is used; it could use the cached authorization token from the user login to query GitHub directly for organizations and teams.

From my PoV this will be a security issue. Storing token that could be retrieved is a bad idea from a security perspective.

samrocketman · 2017-11-07T08:34:20Z

The case you mentionned currently did not work either. With current version if you use Github Token or Login you will have the correct authorization but with Jenkins API Token, you will simply be authenticated.

Yes if using a Jenkins API token, but a user is not granted additional authorization that they don't have. Granting authorizations which have been revoked in GitHub is not desired behavior. The case I mentioned works if the user is using a GitHub personal access token to interact with the Jenkins API.

From my PoV this will be a security issue. Storing token that could be retrieved is a bad idea from a security perspective.

I don't really see much difference from plugins configuring tokens for authorization with GitHub. Other GitHub applications store this token to interact with GitHub on the user's behalf (of which the user consents). As long as the stored token is secured using the credentials API (or at the very least hudson.util.Secret) AND it is not retrievable by non-admins I don't really see the security concern. Otherwise, one could argue using Jenkins for credential storage would be a security concern.

stephenc · 2017-11-07T09:24:42Z

As long as the stored token is secured using the credentials API (or at the very least hudson.util.Secret) AND it is not retrievable by non-admins

The credentials api is not a match for storage of such details.

I would recommend storing the oauth token in Secret or using a similar mechanism with a realm specific key derived from the instance master key.

jglick

I guess? Do not understand well enough to review seriously.

jglick · 2017-11-07T16:24:37Z

src/test/java/org/jenkinsci/plugins/Jenkins47113.java

+     * https://developer.github.com/v3/orgs/
+     * https://developer.github.com/v3/orgs/teams/
+     */
+    private static class MockGithubServlet extends DefaultServlet {


Can also try using WireMock. Cf. discussion in jenkinsci/jenkins-test-harness#39 and linked PRs.

jglick · 2017-11-07T16:46:54Z

From out-of-band discussion: I suspect that the root problem here is that JENKINS-20064 should never have been using SecurityListener to begin with, or at least not mandating it. Rather, a SecurityRealm should be in charge of supplying granted authorities for a user ID in all access modes including REST/CLI. LastGrantedAuthoritiesProperty may be a decent default implementation for a typical password-based realm but this plugin may prefer to use a more finely tuned policy.

AbstractPasswordBasedSecurityRealm.createSecurityComponents already uses ImpersonatingUserDetailsService so why does User.impersonate rewrap the result (whether the realm wants it or not)? This seems suspicious.

samrocketman

Blocking because of security issue. Authorizations should not be granted to a user when authorized access is revoked in GitHub.

Wadeck · 2017-11-08T07:25:54Z

@samrocketman you're right, I will propose a modification in that way: i.e. storing the oauth token in Secret as mentioned by Stephen and not triggering the loggedIn event for the moment. Ideally we desire to have such event triggered for audit / log purpose.

samrocketman · 2017-11-08T07:38:53Z

@Wadeck I appreciate you opening this change and starting this dialogue. I agree the Jenkins token was a bit of a black sheep. Hopefully, this gets resolved and other forms of auth in Jenkins benefit as well (such as SSH keys).

…r in a UserProperty. - also the loggedIn event trigger is removed to avoid cache problem with LastGrantedAuthorities

Wadeck · 2017-11-14T14:04:39Z

@samrocketman new version proposed: we store the access token in a UserProperty and use it to retrieve the real information when the user is authenticated by API Token per example.
I removed the loggedIn event trigger since it's problematic with the LastGrantedAuthorities like discussed. Can you review it ? 🙏

@stephenc can you just check the usage of Secret in order to be sure I'm not making mistakes.

@jglick I investigated your point and I agree the implementation of LastGrantedAuthorities overcome the SecurityListener initial responsability. The idea of providing some caching feature for the SecurityListener could be interesting.

samrocketman · 2017-11-14T16:23:33Z

I shall review this evening after work hours. I'll also build and play with it. Thanks!

samrocketman · 2017-12-05T16:58:02Z

Sure, I'll get that information for you this evening after work.

samrocketman · 2017-12-06T03:33:19Z

Expand the following details to see plugin versions

Jenkins version and plugins versions

Jenkins version 2.73.1
ace-editor 1.1
ant 1.7
antisamy-markup-formatter 1.5
authentication-tokens 1.3
blueocean 1.2.4
blueocean-autofavorite 1.0.0
blueocean-bitbucket-pipeline 1.2.4
blueocean-commons 1.2.4
blueocean-config 1.2.4
blueocean-dashboard 1.2.4
blueocean-display-url 2.1.0
blueocean-events 1.2.4
blueocean-git-pipeline 1.2.4
blueocean-github-pipeline 1.2.4
blueocean-i18n 1.2.4
blueocean-jira 1.2.4
blueocean-jwt 1.2.4
blueocean-personalization 1.2.4
blueocean-pipeline-api-impl 1.2.4
blueocean-pipeline-editor 1.2.4
blueocean-pipeline-scm-api 1.2.4
blueocean-rest 1.2.4
blueocean-rest-impl 1.2.4
blueocean-web 1.2.4
bouncycastle-api 2.16.2
branch-api 2.0.11
build-timeout 1.18
cloudbees-bitbucket-branch-source 2.2.3
cloudbees-folder 6.1.2
credentials 2.1.16
credentials-binding 1.13
display-url-api 2.0
docker-commons 1.8
docker-workflow 1.13
durable-task 1.14
email-ext 2.60
external-monitor-job 1.7
favorite 2.3.0
git 3.5.1
git-client 2.5.0
git-server 1.7
github 1.28.0
github-api 1.89
github-branch-source 2.2.3
github-oauth 0.28-SNAPSHOT (private-ed74c068-sam)
gradle 1.27.1
handlebars 1.1.1
htmlpublisher 1.14
icon-shim 2.0.3
jackson2-api 2.7.3
jira 2.4.2
jquery-detached 1.2.1
junit 1.21
ldap 1.17
mailer 1.20
mapdb-api 1.0.9.0
matrix-auth 1.7
matrix-project 1.11
mercurial 2.1
momentjs 1.1.1
pam-auth 1.3
pipeline-build-step 2.5.1
pipeline-github-lib 1.0
pipeline-graph-analysis 1.5
pipeline-input-step 2.8
pipeline-milestone-step 1.3.1
pipeline-model-api 1.2.1
pipeline-model-declarative-agent 1.1.1
pipeline-model-definition 1.2.1
pipeline-model-extensions 1.2.1
pipeline-rest-api 2.9
pipeline-stage-step 2.2
pipeline-stage-tags-metadata 1.2.1
pipeline-stage-view 2.9
plain-credentials 1.4
pubsub-light 1.12
resource-disposer 0.8
scm-api 2.2.2
script-security 1.34
sse-gateway 1.15
ssh-credentials 1.13
ssh-slaves 1.21
structs 1.10
subversion 2.9
timestamper 1.8.8
token-macro 2.3
variant 1.1
windows-slaves 1.3.1
workflow-aggregator 2.5
workflow-api 2.22
workflow-basic-steps 2.6
workflow-cps 2.41
workflow-cps-global-lib 2.9
workflow-durable-task-step 2.15
workflow-job 2.14.1
workflow-multibranch 2.16
workflow-scm-step 2.6
workflow-step-api 2.13
workflow-support 2.15
ws-cleanup 0.34

By this point the versions of Jenkins and plugins are out of date. I can try upgrading and cut a new build of your pull request.

samrocketman · 2017-12-06T04:34:25Z

❌ Testing Jenkins CLI with API token [FAILED]

I'll try to be as exact as possible. Even with the latest build and latest version of Jenkins and plugins, the issue still remains.

Versions of Jenkins and plugins tested

Setup

From the this page https://github.com/samrocketman/jenkins-bootstrap-github-oauth/releases/tag/pr-87-30d61ed

Download your choice of RPM or DEB. It contains a packaged version of Jenkins and every plugin I had installed during testing.

Download the github-oauth.hpi (or build your own). That binary is specifically from commit 30d61ed.

Provision your own VM which supports RPM or DEB packages. It should have at least 6GB of RAM and 2 CPUs are recommended.

Alternatively, if you prefer vagrant then follow the instructions in the jenkins bootstrap README.

If you install the package Jenkins can be started as a service with the following command:

/etc/init.d/jenkins start

Configure Jenkins

When Jenkins is listening on http://localhost:8080/ or wherever you set up Jenkins. The following needs to be done.

Configure the stable GitHub Authentication Plugin according to the wiki.
Log into Jenkins using your GitHub account.
Install your custom github-oauth.hpi from the plugin manager advanced page and visit /restart in the web UI to restart Jenkins to finish upgrading the plugin.
Visit your user configuration page to get the Jenkins API token. See little red box in attached screenshot.

Testing Jenkins CLI

Assuming you're using http://localhost:8080/ for Jenkins run the following commands to test Jenkins CLI.

curl -LO http://localhost:8080/jnlpJars/jenkins-cli.jar
java -jar jenkins-cli.jar -s http://localhost:8080/ -http -auth samrocketman:ab2c1dd55cd00fbac7560979ac1281ee who-am-i

Note: If Jenkins CLI prompts for your private key password; then this is a bug. Temporarily rename your ~/.ssh/id_rsa file when testing. You can rename it back when done testing.

Wadeck · 2017-12-06T15:35:41Z

@samrocketman after lots of efforts I reproduce your problem. I used a GitHub account with not sufficiant amount of org/team to be able to reproduce initially, so using local Jenkins, Vagrant one or even within a VM, the results is always the same ~15s to have the response.

The root cause seems to be a simple timeout on the CLI. When you are using a GitHub account with logs of org / groups, the current implement will loop on each org / then each team to verify the user belongs to them.
In addition, due to the CLI http mode, three requests are made (1) GET /, 2) ?
POST /cli, 3) POST /cli with body ~ "who-am-i"), and so the token verification must be done thrice, hence the timeout.
The CLI has a timeout around one minute.

I will try to find a way to improve the performance (caching ?) without having the same problem as we encountered with LastGrantedAuthorities.

samrocketman · 2017-12-06T15:43:48Z

That makes sense. My account is a member of many organizations and teams.

Strangely, when I use the GitHub personal access token it seems to work. Good investigation @Wadeck.

Wadeck · 2017-12-06T15:48:40Z

@samrocketman after a bit more analysis on the code, the root cause must be found between GithubAuthenticationToken#new and GithubAuthenticationToken#getGrantedAuthorities. The constructor is used when you authenticate with your Github token and the getGrantedAuthorities when you use the API Token.

I suspect the code in the getGrantedAuthorities to be never used before, as I found a bug during this PR (line around 449, the team was passed instead of the team.getName()). I imagine that method use old code and so the "correct" way is just to have a common method between the constructor and that method to speed up the things (and be consistent). This will no additional caching normally.

I'll keep you informed ;)

(and yes also for me, with my GH token very quick and with API Token timeout)

samrocketman · 2017-12-06T15:54:39Z

@Wadeck that being said. Would you like me to merge this and you open a separate PR with the fix? As far as I can tell your code didn't actually break anything.

Wadeck · 2017-12-06T15:56:20Z

@samrocketman yeah good idea, in order to separate things.

samrocketman · 2017-12-06T15:58:12Z

@oleg-nenashev would you mind reviewing again since you have a blocking review?

stale

Wadeck · 2017-12-06T17:10:00Z

When this one is merged, @samrocketman you will be able to redo your testing process on #92 as it corrects the problem (at least for me)

samrocketman · 2017-12-06T17:20:38Z

I'll check this out this evening after work. It will give other reviewers a chance to look before end of day. Thanks for your hard work on this @Wadeck. I know long PR reviews with lots of comments like this one can be cumbersome. I thank you for your patience.

samrocketman · 2017-12-07T05:46:32Z

This pull request also resolves JENKINS-40204.

samrocketman · 2017-12-07T05:49:25Z

@oleg-nenashev @jglick @stephenc @Wadeck @daniel-beck @dwnusbaum

Congratulations, you have earned a 👾 sticker as prize for participating in this pull request! A lot of issues were resolved.

barryhagan · 2018-02-09T21:38:29Z

An unfortunate side effect of this change is now every time my oauth token is updated the SCM Sync configuration plugin (https://plugins.jenkins.io/scm-sync-configuration) commits a change because the token is stored in the user's config.xml.

Wadeck · 2018-02-14T13:54:24Z

@barryhagan does it impact the data integrity or behavior of the plugin by not saving the change ?

If it's "just" some noise in the git repository, I see two possibilities:

need to add a property excluder in the scm-sync-configuration plugin ?
change behavior by only triggering a commit when the config files are changed manually ? (dunno if it's easily possible to know)

WDYT ?

In any case, you can file a ticket in JIRA for that plugin mentionning this PR.

barryhagan · 2018-02-14T16:41:44Z

@Wadeck, it is a noise problem.

The scm-sync-configuration plugin is doing file diffs on the config.xml and committing the changes to a github repo. It does not inspect individual persisted properties, nor should it be doing that.

In my opinion, the github-oauth-plugin should not be using a user property to store this type of cache data since that ends up in config.xml and the value changes each time a user authenticates. Transient cache data does not belong in a config file. I would suggest having it store the oauth token as a Secret in a different file in $JENKINS_HOME/users/:username.

Obviously it was convenient to use the user property interface to store this, and there are no rules about what can be stored that way, but I just don't think this data belongs in the user config file. The behavior of scm-sync-configuration is a symptom.

samrocketman · 2018-02-15T00:32:09Z

I disagree. Jenkins API tokens are stored in the same manner per user. The same thing would happen if one changes their Jenkins API token. This data is specific to users and, for now, should remain.

How frequent is it actually changing the API token? This theoretically shouldn't change all that often per login session. Otherwise tools like Travis CI wouldn't be able vote back to repositories using stored tokens from the user via the authorized app.

Needs more investigation.

barryhagan · 2018-02-15T04:22:02Z

I totally agree that Jenkins API tokens should be stored this way. They don't change unless you intend to change them. They are effectively a password.

The Github access token is being implicitly updated each time there is an oauth flow to create a session cookie for a user. That will cause numerous config changes on an even moderately active installation and now my configuration commit history is a mess. Updating the stored access token on every session login is not really necessary, but it certainly simplifies the lifetime management of that data.

I've reverted to the previous version for now.

samrocketman · 2018-02-15T07:59:03Z

Creating an issue is probably the best course of action. This way additional work can be tracked. There's articles on how to manage tokens better long term https://stackoverflow.com/questions/26902600/whats-the-lifetime-of-github-oauth-api-access-token

Would like an issue, though.

Wadeck added 2 commits November 1, 2017 10:24

[JENKINS-47113] After Github Auth, we expect to retrieve authz groups

146caf6

- add failing test to reproduce the case - after using the github auth, we retrieve the groups normally but for next auth with ApiToken, we do not receive the groups

- add code to make the tests pass

72dd2f6

- add fireLoggedIn after GithubAuth - add fireAuthenticated after GithubToken

- add link to the PR that will remove the "authenticated" role twice

0b865be

Wadeck requested a review from daniel-beck November 1, 2017 11:12

Wadeck added the code review requested label Nov 1, 2017

recampbell requested a review from dwnusbaum November 1, 2017 15:42

dwnusbaum reviewed Nov 1, 2017

View reviewed changes

- split the tests in two like proposed by Devin

20406ec

- add a TODO on the GithubAPITest that use Ignore but should use Assume

- remove commented code about firing loggedIn event when the user is …

06f1e99

…just using Github token

jglick previously approved these changes Nov 7, 2017

View reviewed changes

samrocketman requested changes Nov 7, 2017

View reviewed changes

Wadeck mentioned this pull request Nov 10, 2017

Add a Spy for the SecurityListener jenkinsci/jenkins-test-harness#82

Closed

- rework the solution, this time we store the access token of the use…

b401a70

…r in a UserProperty. - also the loggedIn event trigger is removed to avoid cache problem with LastGrantedAuthorities

Wadeck requested a review from samrocketman November 14, 2017 14:05

Wadeck changed the title ~~[JENKINS-47113] Fire loggedIn event when using Github login~~ [JENKINS-47113] Store the access token after a successful authentication to GitHub Nov 14, 2017

Wadeck changed the title ~~[JENKINS-47113] Store the access token after a successful authentication to GitHub~~ [JENKINS-47113] Populate the authorities after a successful authentication to Github Nov 14, 2017

oleg-nenashev requested review from jglick and oleg-nenashev November 14, 2017 16:44

Wadeck mentioned this pull request Dec 6, 2017

Update the JRE version samrocketman/jenkins-bootstrap-shared#2

Merged

samrocketman approved these changes Dec 6, 2017

View reviewed changes

Merge branch 'master' into JENKINS-47113_FIRE_LOGGED_IN_EVENT

8a53b45

jglick self-requested a review December 6, 2017 16:42

Wadeck mentioned this pull request Dec 6, 2017

[JENKINS-48412] Fix authorities retrieval for API Token #92

Merged

2 tasks

samrocketman merged commit 7e13146 into jenkinsci:master Dec 7, 2017

Wadeck deleted the JENKINS-47113_FIRE_LOGGED_IN_EVENT branch December 7, 2017 08:12

samrocketman removed the code review requested label Dec 12, 2017

samrocketman mentioned this pull request Dec 16, 2017

JENKINS-40204 - Store Github access key after successful login #75

Closed

3 tasks

[JENKINS-47113] Populate the authorities after a successful authentication to Github #87

[JENKINS-47113] Populate the authorities after a successful authentication to Github #87

Uh oh!

Conversation

Wadeck commented Nov 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed changelog entries

Submitter checklist

Desired reviewers

Uh oh!

ghost commented Nov 1, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dwnusbaum Nov 1, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

samrocketman commented Nov 3, 2017

Uh oh!

daniel-beck commented Nov 6, 2017

Uh oh!

samrocketman commented Nov 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Wadeck commented Nov 7, 2017

Uh oh!

samrocketman commented Nov 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stephenc commented Nov 7, 2017

Uh oh!

jglick left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jglick commented Nov 7, 2017

Uh oh!

samrocketman left a comment

Choose a reason for hiding this comment

Uh oh!

Wadeck commented Nov 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samrocketman commented Nov 8, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Wadeck commented Nov 14, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samrocketman commented Nov 14, 2017

Uh oh!

samrocketman commented Dec 5, 2017

Uh oh!

samrocketman commented Dec 6, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samrocketman commented Dec 6, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Setup

Configure Jenkins

Testing Jenkins CLI

Uh oh!

Wadeck commented Dec 6, 2017

Uh oh!

Wadeck commented Nov 1, 2017 •

edited

Loading

dwnusbaum Nov 1, 2017 •

edited

Loading

samrocketman commented Nov 7, 2017 •

edited

Loading

samrocketman commented Nov 7, 2017 •

edited

Loading

Wadeck commented Nov 8, 2017 •

edited

Loading

samrocketman commented Nov 8, 2017 •

edited

Loading

Wadeck commented Nov 14, 2017 •

edited

Loading

samrocketman commented Dec 6, 2017 •

edited

Loading

samrocketman commented Dec 6, 2017 •

edited

Loading

samrocketman commented Dec 6, 2017 •

edited

Loading

Wadeck commented Dec 6, 2017 •

edited

Loading

samrocketman commented Dec 6, 2017 •

edited

Loading

samrocketman commented Feb 15, 2018 •

edited

Loading

samrocketman commented Feb 15, 2018 •

edited

Loading