Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problem Compiling Source Code #12

Closed
cmcheungMOOC opened this issue Oct 8, 2018 · 12 comments
Closed

Problem Compiling Source Code #12

cmcheungMOOC opened this issue Oct 8, 2018 · 12 comments
Assignees
@awittha
Labels
timeout Additional information or feedback was needed but not provided in a reasonable amount of time.

Comments

@cmcheungMOOC
Copy link

Expected Behavior

mvn compile should work without error.

Actual Behavior

I ran mvn compile at two different directories.
From jenkins-spock directory:
[ERROR] Failed to execute goal on project jenkins-spock: Could not resolve dependencies for project com.homeaway.devtools.jenkins:jenkins-spock:jar:yes: Failed to collect dependencies at org.jenkins-ci.main:jenkins-core:jar:2.102: Failed to read artifact descriptor for org.jenkins-ci.main:jenkins-core:jar:2.102: Could not transfer artifact org.jenkins-ci.main:jenkins-core:pom:2.102 from/to jenkins-releases (http://repo.jenkins-ci.org/releases): Connect to repo.jenkins-ci.org:80 [repo.jenkins-ci.org/130.211.20.35] failed: Connection timed out: connect -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project jenkins-spock: Could not resolve dependencies for project com.homeaway.devtools.jenkins:jenkins-spock:jar:yes: Failed to collect dependencies at org.jenkins-ci.main:jenkins-core:jar:2.102

From shared-library directory
[ERROR] Failed to execute goal on project jenkinsfile-test-shared-library: Could not resolve dependencies for project com.example:jenkinsfile-test-shared-library:jar:0.0.0-SNAPSHOT: Failed to collect dependencies at org.jenkins-ci.main:jenkins-core:jar:2.102: Failed to read artifact descriptor for org.jenkins-ci.main:jenkins-core:jar:2.102: Could not transfer artifact org.jenkins-ci.main:jenkins-core:pom:2.102 from/to jenkins-releases (http://repo.jenkins-ci.org/releases): Connect to repo.jenkins-ci.org:80 [repo.jenkins-ci.org/130.211.20.35] failed: Connection timed out: connect -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project jenkinsfile-test-shared-library: Could not resolve dependencies for project com.example:jenkinsfile-test-shared-library:jar:0.0.0-SNAPSHOT: Failed to collect dependencies at org.jenkins-ci.main:jenkins-core:jar:2.102

Steps to Reproduce

The mvn compile was performed on a Windows box.

  1. Install Java JDK 8
  2. Install Groovy 2.5.2
  3. Install Maven on Windows
  4. Clone Jenkins-Spock
  5. Run mvn compile at the two directories above.

Additional Information

I am beginning to suspect that I don't need to do the build myself to use Jenkins-Spock. If so, can you provide me with some pointers? I am still trying to make sense of the Java ecosystem.
@awittha
Copy link
Contributor

awittha commented Oct 10, 2018

I am beginning to suspect that I don't need to do the build myself to use Jenkins-Spock. If so, can you provide me with some pointers?

This is totally correct - jenkins-spock is available for download in a JAR from the Maven Central repository: https://search.maven.org/search?q=a:jenkins-spock

Your build tools - like maven and gradle - will be able to retrieve the necessary code from there even if you never build jenkins-spock locally.

The example repositories are provided to show what a project that uses jenkins-spock might look like.

You only need to build jenkins-spock yourself if you want to make changes to how it works - you don't need to build it to use it.

@awittha
Copy link
Contributor

awittha commented Oct 10, 2018

Could not transfer artifact org.jenkins-ci.main:jenkins-core:pom:2.102 from/to jenkins-releases (http://repo.jenkins-ci.org/releases): Connect to repo.jenkins-ci.org:80 [repo.jenkins-ci.org/130.211.20.35] failed: Connection timed out: connect -> [Help 1]

I am able to connect to http://repo.jenkins-ci.org/releases just fine right now from my personal machine... A connection timeout on port 80 suggests one of the following:

  1. jenkins-ci.org was down at the time you tried to build the project
  2. the machine you tried to build on wasn't able to establish a network connection to jenkins-ci.org

Are you able to access http://repo.jenkins-ci.org/releases in

  1. a browser window?
  2. from a command-line tool (like curl or wget)?

@cmcheungMOOC
Copy link
Author

cmcheungMOOC commented Oct 12, 2018 via email

@awittha
Copy link
Contributor

awittha commented Oct 15, 2018

BTW, what do you use to generate code coverage percentages?

I haven't figured that out for Jenkins Pipeline code.

Most of the pipeline scripts are loaded as groovy scripts - not as compiled JVM code - so traditional code-coverage tools won't work. I haven't explored code coverage tools for Groovy scripts.

@awittha
Copy link
Contributor

awittha commented Oct 15, 2018

(Looking forward to your pull request!)

@cmcheungMOOC
Copy link
Author

cmcheungMOOC commented Oct 16, 2018 via email

@awittha
Copy link
Contributor

awittha commented Oct 18, 2018

@cmcheungMOOC , I think when you reply to an Issue e-mail with an attachment, GitHub discards the attachment - I don't see your guide on GitHub.com, nor in my inbox.

Can Jenkins-Spock handle Declarative Pipelines?

No, not the way you're thinking.

It will handle declarative pipelines "properly" if you add the declarative pipeline plugin as a dependency... But all "declarative pipeline" is is a Jenkins Pipeline Step named pipeline that consumes the declarative pipeline specification as data.

So, it will be mocked and you can interact with the declarative pipeline specification in your Spock unit tests... but the declarative pipeline specification is data, not executable code. The implementation of the pipeline step does things based on that input data - but that code does not live in jenkins-spock.

Unit-testing a declarative pipeline specification is similar to asking to unit-test an XML or YAML file - it's data: it doesn't make sense to unit-test it.

You might want to check it against a schema, or make assertions about the structure of the data.

jenkins-spock does not currently have any tooling to assist with this.

If Jenkins-Spock cannot handle Declarative Pipelines, what do you
suggest I do?

Short-term, I don't have any path that will accelerate you: someone will have to investigate and determine if it's possible to use the declarative pipeline engine's code in conjunction with Spock, to allow users to

  1. Validate their pipeline declaration
  2. Make assertions about the structure of their pipeline declaration

I do believe that would be a valuable enhancement.

@cmcheungMOOC
Copy link
Author

cmcheungMOOC commented Oct 22, 2018 via email

@awittha
Copy link
Contributor

awittha commented Oct 23, 2018 •
edited

Does Jenkins-Spock support Spy()?

I don't believe it does anything that will block Spy().

But, classes and loadPipelineScriptForTest probably shouldn't be used together: loadPipelineScriptForTest loads Groovy scripts into a groovy.lang.Script object.

If you have a real Groovy class, you don't need loadPipelineScriptForTest; you can just test that class normally:

MyTestSubjectClassSpec.groovy:

public class MyTestSubjectClassSpec extends JenkinsPipelineSpecification {

	def "some specification"() {
		setup:
			MyTestSubjectClass myspy = Spy()
			myspy().someMethod(_) >> {
				// some stubbed behavior
			}
		when:
			myspy.doSomething()
		then:
			1 * myspy.someExpectedMethod()
	}
}

(or similar)

@cmcheungMOOC
Copy link
Author

cmcheungMOOC commented Oct 25, 2018 via email

@awittha
Copy link
Contributor

awittha commented Nov 5, 2018

So basically you are saying that I cannot stub out methods of my test
subject.

No, you should be able to do that. If your Jenkinsfile has methods defined in it, you should be able to Spy() on the object that comes out of loadPipelineScriptForTest(...). I have not tried this, though!

Is the fact that the test subject is loaded into a Groovy script object the reason I cannot get code coverage results?

Yes. Groovy "scripts" start their life as plain text (not source code), and are loaded at runtime. Most code-coverage tools I've seen rely on instrumenting the JVM and/or the bytecode, to connect method calls to source code.

There isn't "source code" in the way those tools are expecting, nor is there any bytecode that maps to the source file.

I do not know of a solution to this.

@awittha awittha self-assigned this Nov 6, 2018
@awittha
Copy link
Contributor

awittha commented Nov 20, 2018

@cmcheungMOOC , do you still need assistance with this issue?

@awittha awittha added the timeout Additional information or feedback was needed but not provided in a reasonable amount of time. label Dec 11, 2018
@awittha awittha closed this as completed Dec 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@awittha awittha

Labels
timeout Additional information or feedback was needed but not provided in a reasonable amount of time.
Milestone
No milestone
Development

No branches or pull requests
2 participants
@awittha @cmcheungMOOC