gitRepo resource getting new versions when it shouldn't

[oyving]

We have a few gitRepo resources defined as follows:

  - name: mlsuite-imaged-github
    type: gitRepo
    integration: github
    versionTemplate:
      sourceName: AIAScience/MLSuite
      branch: master
      buildOnCommit: false

These resources are OUT for some runSh jobs and act as IN for jobs further downstream. The intended effect is that our runCI job will build master branch, and on success publish a version and git state for the other jobs to use.

However, we are seeing these gitRepo resources being triggered even when we are not making commits to the master branch. Is there a bug or did we misunderstand something?

[trriplejay]

the "branch" defined in the versionTemplate governs which webhooks it pays attention to, however since your resource is only updated via replicate action, it will always replicate the specified resource, regardless of branch settings.

I don't think there's any way to avoid this right now. I'll open a feature request to have replicate follow branch settings.

If this is critical, i think we could come up with a script workaround that manually performs the same actions that a replicate does, but include some extra conditionals for checking the branch. would you be interested in that? otherwise, we can update here when the feature gets scheduled for release.

[oyving]

It would be great if we could have such a script until this feature is in place. Right now our pipeline is pushing untested code into production.

Would it be possible to schedule a meeting with you and do a review of our setup? I feel like we might be doing something wrong - or at least using your features in unintended ways. Using Shippable in idiomatic ways might help us run into less issues than we are right now.

[manishas]

We can do a meeting and go over your setup... what time zone are you in? Let me know a few times that work and we can get that set up.

[oyving]

I am in CEST. I can pretty much have a meeting at any time between 9pm and 12pm my time. The sooner the better.

[oyving]

Hi?

[manishas]

@oyving can you clarify the time slots that work for you again? We're in PST.

[oyving]

Alright. Let us set up a call at 8am tomorrow CEST. That should be around 11pm today your time. We can use https://appear.in/aia-shippable to discuss the matter. Please confirm.

[manishas]

@oyving I need a little more lead time to set up a call with the team. Can I get your email address so I can send over a couple of times that work for us? We can coordinate over email. My email is manisha@shippable.com

[trriplejay]

Hi @oyving , we've just released a feature that will help you accomplish what you want. The steps to utilize it for your scenario look like this:

• remove the replicate: true flag from the gitRepo OUT step
• add this shipctl command to the script section of your runSh yml where the gitRepo is an OUT:

shipctl replicate <in repo resource name> <out repo resource name> --match-settings

What this will do is compare the branch settings of the OUT to the shaData of the IN. If the IN commit was for a branch that the OUT is not configured to watch, then the replicate will not happen. In your example, the OUT would only be updated if the IN was processing a commit to master.

You can find more information about the replicate command here: http://docs.shippable.com/platform/tutorial/workflow/using-shipctl/#replicate