Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On the new workflow and pull request standards #300

Closed
Thomas-Boi opened this issue Sep 30, 2020 · 1 comment · Fixed by #301, #290 or #281
Closed

On the new workflow and pull request standards #300

Thomas-Boi opened this issue Sep 30, 2020 · 1 comment · Fixed by #301, #290 or #281
Labels
discussion Use this label for community discussions about changes/features/..

Comments

@Thomas-Boi
Copy link
Member

Thomas-Boi commented Sep 30, 2020

Hey everyone,

So @amacado and I discussed with other on how the branches and build icons will work from now on. Below is what we talked about and the decisions that we arrived at. If anyone has any further inputs on how the build script should work, feel free to leave a comment below this post.

Our Discussions:

  • Creating a new develop branch.

    • Currently, the build script can’t push local master to remote master. The bot doesn’t have permission to do it and we don’t want the bot to have that permission. This is because we want to review the PR before we merge anything in to the master branch.
    • Our Solution:
      • Let the bot not trigger on push/pr into specific branch. Instead, trigger the build when someone adds a specific label to their PR.
        • Only people with write permission can add labels to the PRs. This would not trigger the build script for non-valid branches and remove unnecessary run-time + notifications.
      • Instead of publishing the result back into the contributor's branch as we are doing, the bot would create a new branch (foo) that has the changes and open a PR for foo into this branch.
        • This is done so that the contributor can see their new icons in the index.html and fix any issues if needed. They will then decide whether to accept the changes into the branches.
  • What the new workflow will look like (the CONTRIBUTING.md will be updated with this content):

    • Contributor (Charlie) read CONTRIBUTING.md
    • Charlie will fork our repo and create a new branch from “develop”. They would name it feature/{{id-of-issue}}-{{description}} according to our standards, ex. feature/104-angularjs.
    • They would add their icons to our repo and their icon info to the devicon.json. They must ensure their fonts are ok (visually correct, in the correct folder etc…) before continuing.
      • Side note: At least the plain or line version of the icon is required (since those are required for the icon font)
    • Charlie then commit their changes and create pull requests from their branch into the devicon/develop branch.
      • They must create a separated pull request for each icon (no matter how many variations)
      • They must also include the name of the icon in the pull request f.e. "new icon: html5 (original, plain, line)"
      • Optional: Add a image of the new icon(s) to the description of the pull request
      • Optional: Reference the issues regarding the new icon
    • Collaborators/maintainers (say Mike) would review their branches (assign the reviewer so other collaborators don’t redo your work)
    • Mike will add the label bot: build if the PR is valid, else he'd comment and let the contributor know what’s wrong.
    • Once the label bot: build is added, the bot will trigger the build action
    • The build result will be published in a new branch and a pull request is auto created to merge this build branch (build/feature/{{id-of-issue}}-{{description}}) back into the contributor’s branch
    • Charlie will reviews the change. If they are fine with it, they will accept the changes and Mike will merge it into develop
  • Release schedules:

    • We will release the develop branch in master branch when we think it’s a good time for release (ex. in case we don’t have any icons in a particular frame of time) or when it’s a hot fix (ex. broken icons, etc…)
  • Future plans:

    • Update the GitHub Pages.
    • Eventually, master branch will be used to host our (GitHub pages)[https://github.com/migrate gh-pages to master branch #289].
    • Publish npm package.
    • Create build scripts for the above tasks.
  • Label convention for GitHub actions -> have a bot: prefix:

    • bot: build
    • bot: publish
    • bot: release
  • Possible new yml format for our GitHub Actions file:

on:
  label:
    type: [created,edited]
jobs:
 job01:
    // Check for the github.event.label.name, make sure the conditional works. See if we need to use a “IN” operation instead of “==”
    if: github.event.label.name == 'bot: build'
  • The Selenium Issue:
    • This might be from icomoon site’s anti-bot network policy
    • We can’t do anything for now and the script still runs => let's ignore it for now.
@Thomas-Boi
Copy link
Member Author

I will be closing this issue. However, if anyone would like to discuss it, feel free to open another issue referencing this one.

@Thomas-Boi Thomas-Boi unpinned this issue Oct 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Use this label for community discussions about changes/features/..
Projects
None yet
1 participant