Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-2326

Improve just_the_facts.yml by adding a filter to ignore terminated EC2s

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      Currently, "just_the_facts.yml" reports on an EC2 by tag Name.

      Include a filter that will ignore EC2 that are terminated.

        Attachments

          Issue Links

            Activity

            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            Logic for filtering terminated EC2 has been added to the play mentioned in the description PR created.

            Show
            cdias1 Chester Dias (Inactive) added a comment - Logic for filtering terminated EC2 has been added to the play mentioned in the description PR created.
            Show
            cdias1 Chester Dias (Inactive) added a comment - https://bitbucket.org/aloraine/appstore-playbooks/pull-requests/2/igbf-2326-filter-for-the-required-play-has
            Hide
            ann.loraine Ann Loraine added a comment -

            Please read this and use the same workflow for making branches and submitting PRs:

            Key points:

            • Do all work on topic branches, not master branch.
            • Submit PRs from topic branches (on your fork) to master branch (on team repo)
            • Get someone to do first-level review before submitting a PR.
            • Add links to your topic branch in Jira ticket.
            • Nobody should have more than one ticket assigned to them at a time, except for in the "To-Do" column. In that case, those tickets should mainly be things you've already worked on, such as a topic branch that got put back into "To-Do" because a change request. Or, they could be things you personally want to work on – because you think it would be fun to do or because you're the only person who can do it!

            For this particular issue, it should go into the "Needs first level review" column for a bit so that I or someone else can take a look. If the reviewer has no changes requests, they'll move the ticket forward into "Ready for Pull Request" and re-assign it to yourself. At that point, submit a PR.

            The goal here is to avoid a bunch of PRs piling up because merging is harder for older PRs.

            Chester Dias

            Show
            ann.loraine Ann Loraine added a comment - Please read this and use the same workflow for making branches and submitting PRs: https://canvas.instructure.com/courses/1164217/pages/understand-igb-development-workflow?module_item_id=12709540 Key points: Do all work on topic branches, not master branch. Submit PRs from topic branches (on your fork) to master branch (on team repo) Get someone to do first-level review before submitting a PR. Add links to your topic branch in Jira ticket. Nobody should have more than one ticket assigned to them at a time, except for in the "To-Do" column. In that case, those tickets should mainly be things you've already worked on, such as a topic branch that got put back into "To-Do" because a change request. Or, they could be things you personally want to work on – because you think it would be fun to do or because you're the only person who can do it! For this particular issue, it should go into the "Needs first level review" column for a bit so that I or someone else can take a look. If the reviewer has no changes requests, they'll move the ticket forward into "Ready for Pull Request" and re-assign it to yourself. At that point, submit a PR. The goal here is to avoid a bunch of PRs piling up because merging is harder for older PRs. Chester Dias
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            I had not seen this doc link before. I will follow it, thanks for letting me know.

            Show
            cdias1 Chester Dias (Inactive) added a comment - I had not seen this doc link before. I will follow it, thanks for letting me know.
            Hide
            ann.loraine Ann Loraine added a comment -

            Thank you for understanding. I never told you about it until now.

            Show
            ann.loraine Ann Loraine added a comment - Thank you for understanding. I never told you about it until now.
            Hide
            cdias1 Chester Dias (Inactive) added a comment - - edited

            Hi Dr Loraine,
            First-Level Review Request: Please review the branch containing the code base for the current ticket.
            https://bitbucket.org/chesterdias/appstore-playbooks-igbf-2318/branch/IGBF-2326#diff

            Show
            cdias1 Chester Dias (Inactive) added a comment - - edited Hi Dr Loraine, First-Level Review Request: Please review the branch containing the code base for the current ticket. https://bitbucket.org/chesterdias/appstore-playbooks-igbf-2318/branch/IGBF-2326#diff
            Hide
            ann.loraine Ann Loraine added a comment -

            A note on the process:
            When you are ready for first level review, move the ticket into the "Needs First Level Review" column (as you have done) but also please un-assign it. That lets everybody know it is ready for someone else to pick it up and do the review.
            cc: Chester Dias

            Show
            ann.loraine Ann Loraine added a comment - A note on the process: When you are ready for first level review, move the ticket into the "Needs First Level Review" column (as you have done) but also please un-assign it. That lets everybody know it is ready for someone else to pick it up and do the review. cc: Chester Dias
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            sure. Done. Thanks for letting me know

            Show
            cdias1 Chester Dias (Inactive) added a comment - sure. Done. Thanks for letting me know
            Hide
            ann.loraine Ann Loraine added a comment -

            Two requests:

            1) Please edit above link to the branch using this convention (example):

            This makes it easier to find the exact changes on the branch.

            2) Add a Jira link to your repository.

            Choose Settings > Links > Add new Link

            Then choose:

            Link type: Jira
            Link url: https://jira.transvar.org/
            Link key: IGBF

            click Save to save the link.

            Show
            ann.loraine Ann Loraine added a comment - Two requests: 1) Please edit above link to the branch using this convention (example): https://bitbucket.org/aloraine/appstore-playbooks/branch/IGBF-2307#diff This makes it easier to find the exact changes on the branch. 2) Add a Jira link to your repository. Choose Settings > Links > Add new Link Then choose: Link type: Jira Link url: https://jira.transvar.org/ Link key: IGBF click Save to save the link.
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            Done.

            Show
            cdias1 Chester Dias (Inactive) added a comment - Done.
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            One last (final) request:

            Please edit the commit message - remote ":" and replace with "-" in the jira ticket name so that bitbucket can build a link back to the ticket itself.

            e.g.,

            change to:

            IGBF-2326 Filter for the required play has been added to ignore the terminated instances

            from

            IGBF:2326 Filter for the required play has been added to ignore the terminated instances

            Also, since you will be needing to edit the commit message, do please edit the message to use imperative voice following the convention in https://chris.beams.io/posts/git-commit/

            This makes it much easier to scan loads of commit messages and quickly understand the evolution of the code.

            Some illustrations!

            terrible - just a noun only:

            • IGBF-12345 Sandwich

            better, but not imperative voice and no reason supplied for the commit:

            • IGBF-12345 Sandwich was made

            getting better - imperative voice but no reason supplied as yet:

            • IGBF-12345 Make a sandwich

            best so far! imperative voice and reason supplied for the commit:

            • IGBF-12345 Make a sandwich to feed the hungry

            or

            Show
            ann.loraine Ann Loraine added a comment - - edited One last (final) request: Please edit the commit message - remote ":" and replace with "-" in the jira ticket name so that bitbucket can build a link back to the ticket itself. e.g., change to: IGBF-2326 Filter for the required play has been added to ignore the terminated instances from IGBF:2326 Filter for the required play has been added to ignore the terminated instances Also, since you will be needing to edit the commit message, do please edit the message to use imperative voice following the convention in https://chris.beams.io/posts/git-commit/ This makes it much easier to scan loads of commit messages and quickly understand the evolution of the code. Some illustrations! terrible - just a noun only: IGBF-12345 Sandwich better, but not imperative voice and no reason supplied for the commit: IGBF-12345 Sandwich was made getting better - imperative voice but no reason supplied as yet: IGBF-12345 Make a sandwich best so far! imperative voice and reason supplied for the commit: IGBF-12345 Make a sandwich to feed the hungry or IGBF-12345 Make a sandwich as requested by https://xkcd.com/149/
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            Also, it is totally fine to re-write the commit history of a branch that has not yet been merged in master. Think of it as your own (mostly) private playground to do whatever you want.

            Once you are ready to submit a PR, typically you will squash the commits into one single commit. his makes it much easier later on to cherrypick your commit into other branches as needed. Also, it makes training new people much easier because they can more easily view and comprehend the final changes made by a developer to a solve a problem.

            Show
            ann.loraine Ann Loraine added a comment - - edited Also, it is totally fine to re-write the commit history of a branch that has not yet been merged in master. Think of it as your own (mostly) private playground to do whatever you want. Once you are ready to submit a PR, typically you will squash the commits into one single commit. his makes it much easier later on to cherrypick your commit into other branches as needed. Also, it makes training new people much easier because they can more easily view and comprehend the final changes made by a developer to a solve a problem.
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            Comment amended to link to Jira

            Show
            cdias1 Chester Dias (Inactive) added a comment - Comment amended to link to Jira
            Show
            cdias1 Chester Dias (Inactive) added a comment - https://bitbucket.org/chesterdias/appstore-playbooks-igbf-2318/branch/IGBF-2326#diff
            Hide
            ann.loraine Ann Loraine added a comment -

            Please submit PR when convenient.

            Show
            ann.loraine Ann Loraine added a comment - Please submit PR when convenient.
            Show
            cdias1 Chester Dias (Inactive) added a comment - PR submitted...awaiting for merge approval https://bitbucket.org/aloraine/appstore-playbooks/pull-requests/3/igbf-2326-filter-for-ignoring-terminated
            Hide
            ann.loraine Ann Loraine added a comment -

            PR request was going to my fork. I merged it before realizing it was going to my fork not the team repository. Normally PRs should go to the team repository, not our forks. So I just now submitted a PR to the team repository and merged it.

            Show
            ann.loraine Ann Loraine added a comment - PR request was going to my fork. I merged it before realizing it was going to my fork not the team repository. Normally PRs should go to the team repository, not our forks. So I just now submitted a PR to the team repository and merged it.
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            my mistake.sorry

            Show
            cdias1 Chester Dias (Inactive) added a comment - my mistake.sorry
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            Functionality works post merge

            Show
            cdias1 Chester Dias (Inactive) added a comment - Functionality works post merge

              People

              • Assignee:
                cdias1 Chester Dias (Inactive)
                Reporter:
                ann.loraine Ann Loraine
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: