trigger preview image build on tag

[AndrewChubatiuk]

What type of PR is this?

trigger pipelines on tags

• [ ] Refactor
• [ ] Feature
• [x] Bug Fix
• [ ] New Query Runner (Data Source)
• [ ] New Alert Destination
• [ ] Other

Description

How is this tested?

• [ ] Unit tests (pytest, jest)
• [ ] E2E Tests (Cypress)
• [ ] Manually
• [ ] N/A

Related Tickets & Documents

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 63.76%. Comparing base (372adfe) to head (a1ad984). Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6933   +/-   ##
=======================================
  Coverage   63.76%   63.76%           
=======================================
  Files         161      161           
  Lines       13085    13085           
  Branches     1812     1812           
=======================================
  Hits         8344     8344           
  Misses       4438     4438           
  Partials      303      303           

[eradman]

The format for a tagged image previous should be YY.MM.0-dev; this change does not appear to address that

[AndrewChubatiuk]

The format for a tagged image previous should be YY.MM.0-dev; this change does not appear to address that

this workflow creates a tag YY.MM.0-dev based on cron event, and preview image workflow will build it. what else do you expect?

[eradman]

If we are going to push a new docker image for each commit, I think we should create two different workflows:

1. trigger when tag *-dev is added
2. trigger when a commit is added to master

This does results in duplicate configuration, but I find workflows very tedious to test properly, so the conditions need to be as simple as possible.

@justinclift what do you think?

[AndrewChubatiuk]

I've tested these changes in my fork. it works as expected

[justinclift]

If we are going to push a new docker image for each commit ...

Personally, I think we should have some kind of docker image that always has the latest and greatest development tip from the master branch.

That has the use of pointing people at it to verify a fix they reported (or need for some reason), and it's also useful for us to try out.

That being said, we also need a more stable image we can recommend to people, as we work towards an official, proper release. The preview Docker image (that was previously based upon automatic monthly snapshot) seems like a good idea. Though we should think about how we're going to stabilise that prior to making it an official release.

For that, we'll probably need to branch off of master at some near future point, test the heck out of things at that point and fix any bugs we find (applying the fixes both in that branch and in the master branch). After a few iterations of fixes (hopefully not many), it should be a pretty good image for making official.

---

Note that I don't think we need a brand new unique docker image for every commit to master. That's going to be horrible for people to try and figure out what image to grab, and horrible for whoever's looking after the Docker Hub repository (@arikfr presently I think).

[AndrewChubatiuk]

if user wants to have a certain image, which corresponds to a git tag or just a latest image, he has such an option, but at the same time we need to allow people to rely on build they can consider stable themselves. Either monthly images, which are triggered automatically without stable changes with random content inside and without separate release branches for stability fixes or latest images is not a good option for those, who have infrastructure, which scales up and down often enough, especially taking in account amount of developers, who are able to fix Redash issues. It forces users either build images on their own if image, that was build from master or tag are broken or wait till it's fixed and hope, that it will not become broken again soon

[justinclift]

Yeah. I guess I'm thinking we need to think through how to make a stable branch in the near future, which we then test the living heck out of and eventually call it our next release. :smile: