Closed kdykeman closed 6 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/150499729
The labels on this github issue will be updated when the story is started.
Hey @kdykeman. Sounds pretty reasonable. I'll co-opt this issue as a bug for the team to work on.
+1
@dsabeti could we get tags on the cf-smoke-tests repo as well?
@geofffranks, potentially. How would you use it / what do you need it for?
We wanted to run a versioned copy of smoke tests inside a concourse pipeline, directly in the workers, rather than as a bosh errand
Sent from my iPhone
On Aug 28, 2017, at 2:47 PM, David Sabeti notifications@github.com wrote:
@geofffranks, potentially. How would you use it / what do you need it for?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@geofffranks Would it be more helpful if we added tags/branches to cf-smoke-tests that described which version of cf-deployment (rather than cf-smoke-tests-release) to use? Essentially, given that you're running vX.Y of cf-deployment, you can run
cd go/src/github.com/cloudfoundry/cf-smoke-tests
git checkout cfX.Y
ginkgo -r
(It seems to me like adding tags for cf-smoke-tests release still requires you to do an additional lookup, to discover which version of cf-smoke-tests-release has shipped with a cf-deployment.)
So I would trigger on releases of the boshrelease and pull the version into a tag on the tests themselves to grab the code and start testing? Would be nice if I could do that via a concourse resource vs another job manipulating things, but I could make it work.
What about a "latest" tag on the code repo, updates to match the version used in the boshrelease?
Sent from my iPhone
On Aug 28, 2017, at 6:31 PM, David Sabeti notifications@github.com wrote:
@geofffranks Would it be more helpful if we added tags/branches to cf-smoke-tests that described which version of cf-deployment (rather than cf-smoke-tests-release) to use? Essentially, given that you're running vX.Y of cf-deployment, you can run
cd go/src/github.com/cloudfoundry/cf-smoke-tests git checkout cfX.Y ginkgo -r (It seems to me like adding tags for cf-smoke-tests release still requires you to do an additional lookup, to discover which version of cf-smoke-tests-release has shipped with a cf-deployment.)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I guess I was thinking that in Concourse, you'd just specify a tag_filter
on the git resource for cf-smoke-tests:
resources:
- name: cf-smoke-tests
type: git
source:
branch: master
uri: https://github.com/cloudfoundry/cf-smoke-tests.git
tag_filter: cf0.*
The git resource will only update on new refs that match that tag_filter -- so, only versions of cf-smoke-tests that map to a blessed version of cf-deployment -- and automatically check out that ref. Your task would simply do:
cd $GOPATH/src/github.com/cloudfoundry/cf-smoke-tetsts
ginkgo -r
It may be that I'm still not understanding your use case. Is it more valuable to know which bosh release (i.e. cf-smoke-tests-release) is associated with a given commit of cf-smoke-tests?
Tag filter could work, but we probably also want to use the version of cf cli included in the boshrelease as well, since output changes from newer cli's can break older tests.
Sent from my iPhone
On Aug 29, 2017, at 11:55 AM, David Sabeti notifications@github.com wrote:
I guess I was thinking that in Concourse, you'd just specify a tag_filter on the git resource for cf-smoke-tests:
resources:
- name: cf-smoke-tests type: git source: branch: master uri: https://github.com/cloudfoundry/cf-smoke-tests.git tag_filter: cf0.* The git resource will only update on new refs that match that tag_filter -- so, only versions of cf-smoke-tests that map to a blessed version of cf-deployment -- and automatically check out that ref. Your task would simply do:
cd $GOPATH/src/github.com/cloudfoundry/cf-smoke-tetsts ginkgo -r It may be that I'm still not understanding your use case. Is it more valuable to know which bosh release (i.e. cf-smoke-tests-release) is associated with a given commit of cf-smoke-tests?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@geofffranks, I just wrote another story to help out with that last problem: https://www.pivotaltracker.com/story/show/150757907
Essentially, the test suite would fail if your cf CLI is too old. We already have a pattern for this in CATs.
Thanks!
Sent from my iPhone
On Sep 1, 2017, at 4:44 PM, David Sabeti notifications@github.com wrote:
@geofffranks, I just wrote another story to help out with that last problem: https://www.pivotaltracker.com/story/show/150757907
Essentially, the test suite would fail if your cf CLI is too old. We already have a pattern for this in CATs.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@dsabeti could y'all revive this issue? We're currently pinning to random git SHAs in our pipeline, would be nicer if this repo had tags like every other component we pull in. Thanks!
Thanks for chiming in @ljfranklin. This is one of those stories that keeps hanging out at the bottom of the backlog. I've pulled it up a bit higher, so we should try to get to it soon.
We've finally gotten to finishing this story. You should see that the latest release is 40.0.1, and there's a git tag for it. All releases from here on out should have git tags associated with them.
Hi,
When looking through the metadata for Elastic Runtime, I noticed that it includes version "36" of
cf-smoke-tests-release
. It was a bit of an exercise to map that back to commit d12b393. Is there any reason CF MEGA BOT doesn't create tags for these releases?