`GitHubMilestoneApiTests` uses `Instant.now()` for `due_on`. Since
`Instant.now()` is UTC time based,
`isMilestoneDueTodayWhenDueTodayThenTrue` fails when the computer that runs
the test is not the same day as it is in UTC time.
To fix it, `due_on` should be set to an `Instant` based upon the timezone
of the current computer.
Closes gh-11706
`GitHubMilestoneApiTests` uses `Instant.now()` for `due_on`. Since
`Instant.now()` is UTC time based,
`isMilestoneDueTodayWhenDueTodayThenTrue` fails when the computer that runs
the test is not the same day as it is in UTC time.
To fix it, `due_on` should be set to an `Instant` based upon the timezone
of the current computer.
Closes gh-11706
`GitHubMilestoneApiTests` uses `Instant.now()` for `due_on`. Since
`Instant.now()` is UTC time based,
`isMilestoneDueTodayWhenDueTodayThenTrue` fails when the computer that runs
the test is not the same day as it is in UTC time.
To fix it, `due_on` should be set to an `Instant` based upon the timezone
of the current computer.
Closes gh-11706
`GitHubMilestoneApiTests` uses `Instant.now()` for `due_on`. Since
`Instant.now()` is UTC time based,
`isMilestoneDueTodayWhenDueTodayThenTrue` fails when the computer that runs
the test is not the same day as it is in UTC time.
To fix it, `due_on` should be set to an `Instant` based upon the timezone
of the current computer.
Closes gh-11706
This commit merges a workaround to an issue in JFrog's Gradle plugin
which causes SNAPSHOT javadoc and sources to become out of sync and thus
prevents users from being able to download either.
Closes gh-10602
This commit merges a workaround to an issue in JFrog's Gradle plugin
which causes SNAPSHOT javadoc and sources to become out of sync and thus
prevents users from being able to download either.
Closes gh-10602
This commit merges a workaround to an issue in JFrog's Gradle plugin
which causes SNAPSHOT javadoc and sources to become out of sync and thus
prevents users from being able to download either.
Closes gh-10602
Fixes an issue where the first day of the month is (for example) a
Tuesday causing the 2nd Tuesday and 3rd Monday to be over a week apart.
Issue gh-10458
This step introduces the concept of a release train to determine the appropriate release dates and schedules milestones as needed. It uses the following rules:
- If the current SNAPSHOT version is a minor release (patchVersion == 0), checks to see if a GA release exists. If not, a release train is scheduled as follows:
- Finds the next available release train starting month (including this month), either January or July.
- Schedules a release train with M1, M2, M3, RC1 and GA versions on either January/February/March/April/May or July/August/September/October/November
- If the current SNAPSHOT version is a patch release (patchVersion != 0), checks to see if a GA release exists. If not, an individual milestone is scheduled on the next even month whose release day is in the future (can include this month).
- In either case, the release day used to schedule the release is based on the configured weekOfMonth (1-4) and dayOfWeek (1-5), e.g. 3rd Monday of the month (3, 1).
If a milestone already exists, nothing is created. Once created, milestone due dates can be updated manually as desired.
Closes gh-10458
Rather than having the task fail if the milestone is not due today, it now
outputs to a file true or false. This allows the pipeline to determine
if it should continue or not without causing a failure.
Issue gh-11158
Rather than having the task fail if the milestone is not due today, it now
outputs to a file true or false. This allows the pipeline to determine
if it should continue or not without causing a failure.
Closes gh-11158
Add 2 Gradle tasks, one that calculates the next release milestone based on the current version and one that checks if it is due today.
Issue gh-10451
Issue gh-10455
Steve Riesenberg
Josh Cummings
Marcus Da Coregio
Rob Winch
Simone Giannino
Eleftheria Stein