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.

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

[TEST] portable packaging test project + windows #27623

Conversation

andyb-elastic
Copy link
Contributor

This creates projects for new packaging tests
written in groovy that can run on linux and
windows, and adds awareness of windows boxes
to the gradle build and Vagrantfile. No tests
have been ported here, the groovy tests just
exit immediately.

Also creates the project :qa:packaging-common
for code that should be shared between tests,
e.g. the kind of content that lives in the
utils/ portion of the bats tests. This is a
separate project so that extra plugins'
projects may depend on it without conflicting
with the tests' project.

The default is to not test on any windows boxes
unless explicitly specified (we can't provide
windows boxes) to gradle via project properties
or to vagrant via environment variables.

Once the bats tests in :qa:vagrant have all
been migrated, that project can be deleted
and the vagrant test plugin applied to
:qa:packaging directly, making it serve as both
the groovy build for the tests, and the tasks
that setup the VMs the tests run on.

For #26741

This creates projects for new packaging tests
written in groovy that can run on linux and
windows, and adds awareness of windows boxes
to the gradle build and Vagrantfile. No tests
have been ported here, the groovy tests just
exit immediately.

Also creates the project :qa:packaging-common
for code that should be shared between tests,
e.g. the kind of content that lives in the
utils/ portion of the bats tests. This is a
separate project so that extra plugins'
projects may depend on it without conflicting
with the tests' project.

The default is to not test on any windows boxes
unless explicitly specified (we can't provide
windows boxes) to gradle via project properties
or to vagrant via environment variables.

Once the bats tests in :qa:vagrant have all
been migrated, that project can be deleted
and the vagrant test plugin applied to
:qa:packaging directly, making it serve as both
the groovy build for the tests, and the tasks
that setup the VMs the tests run on.

For elastic#26741
@andyb-elastic andyb-elastic added :Delivery/Build Build or test infrastructure >test Issues or PRs that are addressing/adding tests v6.2.0 labels Dec 1, 2017
@@ -0,0 +1,462 @@
# -*- mode: ruby -*-
Copy link
Contributor Author

@andyb-elastic andyb-elastic Dec 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rewrote the Vagrantfile this way at first because it seemed like it made it more readable if you're trying to figure out "what's in all these images" like I was. However it seems like it makes it much less readable if you're trying to figure out "what's in this specific image", so I went with the way it was previously written.

It's not complete here but I figured I'd include it in case others do find it more readable in general - I'll remove if not

Copy-Long-Path C:\\elasticsearch-extra C:\\Users\\vagrant\\elasticsearch-extra
}
""")]
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's worth noting that this task is very slow, on the order of minutes. It seems like it's necessary on windows because the project is mounted in such a way that gradle has trouble running in it - I wasn't able to figure out a workaround. On linux, we can probably avoid it if that's too time consuming

Copy link
Member

@tlrx tlrx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andyb-elastic This is a really great pull request, but I have to admit that it contains too many changes for me to review it correctly. It introduces the new windows boxes but renames tasks, adds new gradle projects, refactors the Vagrantfile and handle specific things like long paths at the same time... Do you think that we could proceed with a feature branch and many small pull requests?

Of course if I'm the only reviewer to have trouble with so many changes at once it does not worth it to proceed as I'm suggesting to do.

@jasontedor
Copy link
Member

I agree, let’s break this one down @andyb-elastic.

@andyb-elastic
Copy link
Contributor Author

Sure thing, I'll break it up into a few. Now that I'm sure this setup works it'll be easier to separate

@tlrx
Copy link
Member

tlrx commented Dec 5, 2017

Thanks @andyb-elastic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team >test Issues or PRs that are addressing/adding tests v6.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants