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.

[kitemongerer]

Is this in the pipeline? We would love this feature as well!

[kmacoskey]

+1 This is still a big workflow issue for pipelines that have nightly/weekly triggers when needing to set a development pipeline. Having an initial_time field implemented and then using an interpolated value would allow us to have production variables that don't set an initial_time (the behavior now), then development credentials that set an initial_time in the past so that the jobs can run immediately.

[benchristel]

+1 ran into this issue when trying to set a dev version of a pipeline with a weekly trigger.

[peterellisjones]

+1 : frequently have this issue and often see it cause confusion when introducing clients to Concourse.

[vito]

(Just doing some issue/RFC networking...)

This would be fixed by concourse/rfcs#24 if we treat the time resource as a trigger resource - it would then be used to trigger on its schedule, but not a hard dependency, so the job could also run without any versions being found initially.

[jamespollard8]

any update on this?

[bruce-ricard]

There is a workaround. If you ask your Concourse to check the resource as of a day far in the past, it will "find" a time-resource version and your job will be able to run.

Run this command:

fly -t <your target> \
   check-resource <your resource>
   --from "time:2000-01-01T00:00:00Z" # the important part

And you are good to go.

[jamespollard8]

Oh cool - thanks!