Adding a zero time

[ggeorgiev]

When a long-term time resource is used - say once per day or week a newly created pipeline is dysfunctional until the timer activates at least once. To overcome this I have to make the time schedule to include the time I am working at to create one version and set the correct ranges after that.

It will be nice if the time resource does this by itself - creating a zero - or any other system time, to unblock the pipeline for testing.

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #131954137 Adding a zero time

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[vito]

Should probably be opt-in. I could definitely see that going wrong otherwise ("why did the prod deploy run during business hours?").

[ggeorgiev]

I am having a docker image that prepares build environment - it collects go vendors etc. It is expensive to do and reloading the image also slows down. This is why I would like to have it updated only after midnight ... and this is how I noticed the time resource issue.

[jtarchie]

After some discussion with the team, having the resource calculate a zero time automagically could have some challenges with keeping track of those versions.

We've decided to go a more explicit route where you can specify an initial_time, which is very similar to the initial_version of the semver resource.

With initial_time, you'll be able to specify a timestamp that will be the first version to appear. Specifying a timestamp also allows it to be consumed via input in the get.

For example,

resources:
- name: 15m
  type: time
  source:
    interval: 15m
    initial_time: Mon Jan 2 15:04:05 -0700 MST 2006

[jtarchie]

After discussion, again, initial_time could imply that it will a starting point for the intervals not just an emitted version. We are thinking about changing it to initial_version just to simplify its implied impact.

[gzamoran-ford]

And when this will be added to Concourse? we are using 3.3.2 and we have this issue

[l-wang]

+1 to having an initial_time field. We are constantly needing to manually modify our time resource when setting development pipeline in order to generate the first version. Many a developer would be happy in removing that from their workflow.