-
Notifications
You must be signed in to change notification settings - Fork 42
Conversation
.ci/Jenkinsfile
Outdated
@@ -35,6 +35,7 @@ pipeline { | |||
string(name: 'SLACK_CHANNEL', defaultValue: 'observablt-bots', description: 'The Slack channel(s) where errors will be posted. For multiple channels, use a comma-separated list of channels') | |||
string(name: 'ELASTIC_AGENT_DOWNLOAD_URL', defaultValue: '', description: 'If present, it will override the download URL for the Elastic agent artifact. (I.e. https://snapshots.elastic.co/7.12.0-069dfaa4/downloads/beats/elastic-agent/elastic-agent-7.12.0-SNAPSHOT-linux-x86_64.tar.gz') | |||
string(name: 'ELASTIC_AGENT_VERSION', defaultValue: '7.x-SNAPSHOT', description: 'SemVer version of the stand-alone elastic-agent to be used for Fleet tests. You can use here the tag of your PR to test your changes') | |||
string(name: 'ELASTIC_AGENT_STALE_VERSION', defaultValue: '7.10.0', description: 'SemVer version of the stale stand-alone elastic-agent to be used for Fleet upgrade tests.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michalpristas what version should we use as stale in 7.x? Same question will come up for the backport to 7.10.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7.x i would keep previous stable
for 7.10.x we could do 7.10.(x-1) or 7.10.0? what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, the stale version is a previous, valid version, right? So:
- For
7.x
branch: current=7.x-SNAPSHOT and stale=? - For
7.10.x
branch: current=7.10-SNAPSHOT and stale=?
Because we are using the alias, which holds a reference to the current moving target, how do we get that (-1)? There is a method to retrieve the current version: GetElasticArtifactVersion
(see 4c1cea5#diff-04a1accd1c12dafffe8d3ecc43a623cd0bf22d03d3561f7e04e296e64962048eR121). What would be the algorithm to rest one to that version? Do you foresee any corner case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in today's conversation, @EricDavisX and I decided we are not going to backport the upgrade tests to 7.10.x
Update: I understood it wrong and we do need to backport this to 7.10.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, @michalpristas @EricDavisX I'd see that in master
branch, the value of the stale agent it should be 7.x-SNAPSHOT, which is ((master-1) == (8.0.0-SNAPSHOT - 1))
, because master is always running in the edge. Wdyt? Or maybe I'm wrong and it needs the latest released artifact.
@michalpristas this PR backports your PR. I'll squash the commits and do same backport to 7.10.x. Do you think that branch needs to receive the backport? |
I agree with 7.x using current minor version minus one as the stale version.
The exceptions are 7.10 and 8.0.
8.0 is 'master' and it can use the 7.x latest major for the 'stale' agent. If it used the latest minus one (if easier) that is ok too, to avoid too much logic here - what ever is quickest is ok by me. |
What does this PR do?
It cherry-picks all commits in that PR, manually resolving conflicts.
Why is it important?
Keep 7.x branch up-to-date
Checklist
make notice
in the proper directory)Author's Checklist
Related issues
Follow-ups
Once merged using squash, try to backport that resulting commit to 7.10.x too