Add renovate.json configuration

[thepetk]

What does this PR do?:

This PR adds the renovate.json configuration for the registry repo. The configuration will cover 2 things:

Stack image updates
The renovate bot will look inside the registry directories for devfile.y(a)ml files and try to update an image (looking for "image:") tag. For every different image found it will create a new PR. So if two different stacks use the same image, one PR will be created updating both image tags. On the other hand if we have 2 different images to update, it will create a PR for each one of them. Note, that images with "latest" tag will not be updated.

In order to remove the usage of variable values or latest (1 case) version, some tags have been updated to a fixed value. For nodeJS 16 the version was taken from all other stacks using the same image. On the first run, renovate should create a PR to update all of them.

Github Actions
Renovate will also look on every run, to update any deprecated github actions. All updates for github actions will be included on the same PR.

Documentation
The contributing.md guide was updated in order to emphasize to the usage of non-latest image tags when creating new stacks

Next steps
After merging this PR we need to follow all instructions here in order to add the registry project to the self hosted renovate bot.

Which issue(s) this PR fixes:

fixes devfile/api#1139

fixes devfile/api#1138

PR acceptance criteria:

• Contributing guide
  Have you read the devfile registry contributing guide and followed its instructions?
• Test automation
  Does this repository's tests pass with your changes?
• Documentation
  Does any documentation need to be updated with your changes?
• Check Tools Provider
  Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)

How to test changes / Special notes to the reviewer:

[michael-valdron]

/retest

[thepetk]

/retest

[michael-valdron]

/retest

[michael-valdron]

Aside from the feedback looks good! You also might need to contact the stack owners for approval on these stack changes.

cc: @BethGriggs @ajm01

[thepetk]

Aside from the feedback looks good! You also might need to contact the stack owners for approval on these stack changes.

cc: @BethGriggs @ajm01

@michael-valdron thanks for the review
I've updated the PR with the suggested changes and I've added @BethGriggs & @ajm01 as reviewers

[yangcao77]

@scottkurz @mezarin Also tagged the java-liberty stack owners to review

[michael-valdron]

I have sent DMs to both @BethGriggs and @ajm01 under the Kubernetes community slack workspace, I would say give them an additional day or so to respond.

[thepetk]

I have sent DMs to both @BethGriggs and @ajm01 under the Kubernetes community slack workspace, I would say give them an additional day or so to respond.

many thanks @michael-valdron and @yangcao77

[openshift-merge-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[yangcao77]

/lgtm

[thepetk]

@ajm01 @mezarin and @scottkurz kind reminder for the review request of this PR :) Thanks a lot!

[michael-valdron]

We have not heard from @ajm01 yet, I recommend we for now revert the changes to the java-openliberty-gradle, java-openliberty, java-websphereliberty-gradle, and java-websphereliberty stacks and add an exclusion in renovate for these stacks.

We can open another PR to reintroduce these changes once we hear back. wdyt?

[scottkurz]

Hi, I'm sorry this slipped past us and I'm just noticing this now.

The bigger issue here is that we have not been very current in updating the Liberty stack images, (the last one was 22.0.0.1). Whether this change is made or not, our image is still almost two years old at this point. Perhaps we need to consider abandoning our custom image and building a devfile based on a well-known Java/Maven image with a "tools"-type of component.

I'm getting ahead of myself. Let's ignore that bigger issue though and just talk through the PR here:

If I understand it correctly, this might not be of too much value given the way the four Liberty stacks are maintained at the moment. They use special-purpose Liberty images developed for devfile use cases (for purposes such as caching Maven dependencies in the image) rather than more general Liberty images.

So for the team updating these stack images, it's not too much more work to send a PR to this devfile registry repo at the same time.

That said, maybe it's still nicer to manage the versions getting updated via renovate and not having this extra PR to approve and merge.

The only problem though is that the two Gradle stacks use the liberty-version variable in the run command:

commandLine: echo "gradle run command"; {{gradle-cmd}} -Dgradle.user.home=/.gradle libertyDev -Pliberty.runtime.version={{liberty-version}} -Pliberty.runtime.name=wlp-javaee8 -Pliberty.runtime.group=com.ibm.websphere.appserver.runtime --libertyDebug=false --hotTests --compileWait=3

So updating the image version without updating this version variable as well could lead to a confused experience.

Not sure where that leaves us. Maybe we should just exempt the Liberty stacks?

[thepetk]

Hi, I'm sorry this slipped past us and I'm just noticing this now.

The bigger issue here is that we have not been very current in updating the Liberty stack images, (the last one was 22.0.0.1). Whether this change is made or not, our image is still almost two years old at this point. Perhaps we need to consider abandoning our custom image and building a devfile based on a well-known Java/Maven image with a "tools"-type of component.

I'm getting ahead of myself. Let's ignore that bigger issue though and just talk through the PR here:

If I understand it correctly, this might not be of too much value given the way the four Liberty stacks are maintained at the moment. They use special-purpose Liberty images developed for devfile use cases (for purposes such as caching Maven dependencies in the image) rather than more general Liberty images.

So for the team updating these stack images, it's not too much more work to send a PR to this devfile registry repo at the same time.

That said, maybe it's still nicer to manage the versions getting updated via renovate and not having this extra PR to approve and merge.

The only problem though is that the two Gradle stacks use the liberty-version variable in the run command:

commandLine: echo "gradle run command"; {{gradle-cmd}} -Dgradle.user.home=/.gradle libertyDev -Pliberty.runtime.version={{liberty-version}} -Pliberty.runtime.name=wlp-javaee8 -Pliberty.runtime.group=com.ibm.websphere.appserver.runtime --libertyDebug=false --hotTests --compileWait=3

So updating the image version without updating this version variable as well could lead to a confused experience.

Not sure where that leaves us. Maybe we should just exempt the Liberty stacks?

Hey! No worries! I think the best options would be to exclude for now those stacks from the automation.

I think we can re-visit those stacks once we have more releases. This way we can have also the time to investigate a solution to use renovate with variables like liberty-version.

Just tfyi, with the current workaround the reviewer would be responsible to update the liberty-version variable value in case of a renovate update.

I'll come back shortly and exclude those stacks from this PR.

cc @michael-valdron @scottkurz

[thepetk]

@scottkurz & @michael-valdron I've reverted all updates to "liberty-related" stacks. I've also added a rule in renovate.json to ignore the paths of these stacks just to unnecessary error logging on the renovate runner.

[michael-valdron]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BethGriggs, michael-valdron, thepetk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [michael-valdron,thepetk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment