Skip to content

Releases: wata727/elastic_whenever

v1.0.1 (2024-01-27)

27 Jan 12:26
Compare
Choose a tag to compare

Bug Fixes

v1.0.0 (2024-01-07)

07 Jan 13:46
Compare
Choose a tag to compare

Although this is a major version release, there are no notable incompatibilities. This means that the current behavior is stable enough that no major future changes are planned at this time.

Enhancements

  • #69: Improve profile support (@mfittko)
    • Previously, a profile passed with the --profile flag was always used only for shared credentials, and could not be used to switch profiles for credentials issued by IAM Identity Center, etc.
    • With this change, the passed profile will be used correctly to other credentials as well.

Chores

v0.7.0 (2021-09-25)

25 Sep 07:32
Compare
Choose a tag to compare

This release contains a major change to the behavior when updating tasks. In most cases, this change has no effect, but be aware of the change in behavior when omitting a revision of the task definition. In particular, if you are building a deployment workflow where the update timing of task definitions and the update timing of scheduled tasks are different, the revisions that are executed may be different.

Breaking Changes

  • #57: Selective Updates (@HistoireDeBabar)
    • Previously, Elastic Whenever recreates all scheduled tasks after deleting all tasks when updating tasks. However, in this case, there is a risk that frequently invoked tasks will not be executed, so this change now creates/deletes only those tasks that have changed.
    • Due to this change, the naming convention for scheduled tasks has changed. When updating from v0.6, all rules will be deleted and recreated due to different naming conventions, and the behavior will be the same as before. After that, the task will not change if the names are the same.
    • The breaking change is that the behavior when omitting a revision of a task definition has changed. Previously, when you created a task, you resolved the latest revision at that time, so even if the task definition was updated, the revision that was executed was always the same. In v0.7 and later, revisions are not resolved when you created a task, so the latest revision is always adopted.

Chores

  • #55: CI against Ruby 3.0
  • #56: Add the rexml dependency explictly
  • #58: Fix typo

v0.6.1 (2020-11-08)

08 Nov 07:36
Compare
Choose a tag to compare

BugFixes

  • #51: Avoid hitting rate limits fetching credentials when running under ECS or with an IAM profile (@stevenwilliamson)

Chores

  • #53: Migrate CI to GitHub Actions from Travis CI

v0.4.0 (2018-12-19)

18 Dec 16:40
Compare
Choose a tag to compare

Elastic Whenever now supports Fargate launch type. Thanks @avinson.

From this release, ECS parameters must be passed as arguments. Previously, it supported schedule file variables, but it will be ignored.

# Before
$ elastic_whenever --set 'cluster=ecs-test&task_definition=oneoff-application:2&container=oneoff'

# After
$ elastic_whenever --cluster ecs-test --task-definition oneoff-application:2 --container oneoff

Enhancements

  • update elastic_whenever for FARGATE launch type (#34)

Changes

  • Bump aws-sdk-cloudwatchevents dependency (#36)
  • Pass ECS params as an argument (#37)

Chore

  • CI against Ruby 2.4.5 and 2.5.3 (#35)
  • Set nil as verbose mode (#38)
  • Revise task's target (#39)