Gitea: Gitea should send tag webhook at release creation on UI

[xoxys]

• Gitea version (or commit ref): 1.7.1
• Git version:
• Operating system: CentOS 7
• Database (use [x]):
  
  
  
  • [X] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [X] Not relevant
  
  
• Log gist:

Description

If a release is created from the UI, gitea should send a tag webhook to trigger some CI Systems.

[xoxys]

Look also https://github.com/go-gitea/gitea/issues/5288

[typeless]

Any ideas or workarounds? I can look into it if this does not require a big change.

I think this is useful. My goal is to have the non-devs in my department (like QA/PM and alike) can create the releases autonomously via the web interface.

[xoxys]

@techknowlogick any chance to get this into gitea?

[xoxys]

@typeless workaround is to create a tag in your local clone and push the tag to gitea. But it's a bit messy :)

[blueworrybear]

@xoxys
Hi, I would like to fix this issue by sending a Push Event Hook when release created.
As I know, there is a func createTag in services\release\release.go, add a webhook event here seems to be a good idea.

However, as mentioned at #5288, Gitea already sends Release Event Hook. Not sure if there is any concern to send an extra webhook event.

I need some suggestions before pushing my codes.

Below is my draft codes (not finished yet):

func createTag(gitRepo *git.Repository, rel *models.Release) error {
  // Only actual create when publish.
  if !rel.IsDraft {
    if !gitRepo.IsTagExist(rel.TagName) {
      commit, err := gitRepo.GetCommit(rel.Target)
      if err != nil {
        return fmt.Errorf("GetCommit: %v", err)
      }

      // Trim '--' prefix to prevent command line argument vulnerability.
      rel.TagName = strings.TrimPrefix(rel.TagName, "--")
      if err = gitRepo.CreateTag(rel.TagName, commit.ID.String()); err != nil {
        if strings.Contains(err.Error(), "is not a valid tag name") {
          return models.ErrInvalidTagName{
            TagName: rel.TagName,
          }
        }
        return err
      }
      rel.LowerTagName = strings.ToLower(rel.TagName)

      // Prepare Webhook
      if err := rel.LoadAttributes(); err != nil {
        log.Error("LoadAttributes: %v", err)
      } else {
        var shaSum string
        mode, _ := models.AccessLevel(rel.Publisher, rel.Repo)
        apiRepo := rel.Repo.APIFormat(mode)
        apiPusher := rel.Publisher.APIFormat()
        shaSum, err = gitRepo.GetTagCommitID(rel.TagName)
        if err != nil {
          log.Error("GetTagCommitID[%s]: %v", rel.TagName, err)
        }
        if err = models.PrepareWebhooks(rel.Repo, models.HookEventPush, &api.CreatePayload{
          Ref:     git.TagPrefix + rel.TagName,
          Sha:     shaSum,
          RefType: "tag",
          Repo:    apiRepo,
          Sender:  apiPusher,
        }); err != nil {
          log.Error("PrepareWebhooks: %v", err)
        } else {
          go models.HookQueue.Add(rel.Repo.ID)
        }
      }
    }
    commit, err := gitRepo.GetTagCommit(rel.TagName)
    if err != nil {
      return fmt.Errorf("GetTagCommit: %v", err)
    }

    rel.Sha1 = commit.ID.String()
    rel.CreatedUnix = timeutil.TimeStamp(commit.Author.When.Unix())
    rel.NumCommits, err = commit.CommitsCount()
    if err != nil {
      return fmt.Errorf("CommitsCount: %v", err)
    }
  } else {
    rel.CreatedUnix = timeutil.TimeStampNow()
  }
  return nil
}

[xoxys]

@blueworrybear sending a push event in case a release was created is not the right solution. As mentinoned in the first post, a tag event is needed

[blueworrybear]

@xoxys
Thanks for your feedback. I had read the first post and understand that creating tag event is needed.
But drone seems to handle tag event during somebody pushed a new tag.
It seems to me that it makes sense if we treat the release creation as someone creates a tag, push it to the remote and update the Gitea page.

In fact, publishing a tag indeed requires push. Therefore sending a push event in the same time seems to be okay.

I think send a tag create and push tag event in the same time is not a big deal. I'll update my code to do so.