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

move ci/logstash_releases.json #2

Open
kares opened this issue Dec 10, 2019 · 1 comment
Open

move ci/logstash_releases.json #2

kares opened this issue Dec 10, 2019 · 1 comment

Comments

@kares
Copy link
Contributor

kares commented Dec 10, 2019

from logstash's repo ... here to be tracked by the .ci repo itself

some period when its in both might be necessary -> or a HTTP MOVED if curl handles that

@yaauie
Copy link
Contributor

yaauie commented Jan 21, 2020

Related, but potentially a tangent.

We can also take advantage of travis's Build Config Imports, which could allow us to maintain a source of truth in a single external repository.

With the existing tooling to resolve MAJOR.x in each plugin, I would imagine having shared configs that look like:

matrix:
  include:
    - ELASTIC_STACK_VERSION=6.x
    - ELASTIC_STACK_VERSION=7.x
    - ELASTIC_STACK_VERSION=7.x SNAPSHOT=true
    - ELASTIC_STACK_VERSION=6.x SNAPSHOT=true

-- logstash-plugins/.ci:travis-include/supported-builds.travis.yml@master

(we could provide similar for INTEGRATION=true variants for plugins that need )

Which could be used in travis configs in individual repos with:

version: ~> 1.0
import:
 - source: logstash-plugins/.ci:travis-include/supported-builds.travis.yml@master

-- logstash-plugins/$plugin:.travis.yml

OR, we could skip the complexities of having each plugin resolve MAJOR.x and just include specific versions in a shared config that we import, giving us a single source of truth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants