One of the most important features in Gradle is the support for incremental tasks. Incremental tasks have input and output properties that can be checked by Gradle. When the values of the properties haven’t changed, then the task can be marked as up to date by Gradle and it is not executed. This makes a build much faster. Input and output properties can be files, directories, or plain object values. We can set a task input property with a date or date/time value to define when a task is up to date for a specific period. As long as the value of the input property hasn’t changed (and of course, also the other input and output property values), Gradle will not rerun task and mark it as up to date. This is useful, for example, if a long-running task (e.g. large integration test suite) only needs to run once a day or another period.
In the following example, in the Gradle build file, we define a new task
Broadcast that will get content from a remote URL and save it in a file. In our case, we want to save the latest messages from SDKMAN!. If you don’t know SKDMAN!, you should check it out!. The
Broadcast task has an incremental task output property, which is the output file of the task:
Serverless has been gaining more and more traction over the last few years, more than 600% in the last quarter of 2017 alone. The time has come when enterprises start looking for ways of decoupling their current monolithic architectures and moving their stack to serverless. Looking back at the container revolution and how long it took for serious enterprises to start banking on it, it’s likely that we’re still a couple of years away but because the rate of adoption has been quicker for serverless, we might see the migration pick up a bit sooner than expected.
Our team at Dashbird has done extensive research about how companies use serverless, what common pain points they have, and how developers go about solving them.